jeudi 15 septembre 2011, 14:20:20 (UTC+0200)

Failles de type XEE dans SharePoint et DotNetNuke

Microsoft vient de publier les bulletins de sécurité du mois de Septembre, dont MS11-074 concernant (entre autres) SharePoint 2007 et 2010. Je dis "entre autres" car les logiciels impactés par CVE-2011-1892 incluent aussi :

  • côté client : Office Groove 2007 et SharePoint Workspace 2010
  • côté serveur : Office Forms Server 2007, Office Groove (Data Bridge|Management) Server 2007, Office Groove Server 2010
  • côté "cloud" : Office Web Apps 2010

Il est à noter que SharePoint 2003 n'est pas vulnérable, car il n'inclut pas le composant Web Part vulnérable.


Pour les personnes ne pratiquant pas couramment SharePoint, un "Web Part" (parfois appelé "Web Widget" ou "Portlet") est un composant ASP.Net exécuté côté serveur et intégrable depuis un navigateur à toute page accessible en modification. Le composant "XML Web Part" prend en paramètre des données (sous forme XML) et du code de mise en page (sous forme XSL) et renvoie le code XHTML correspondant aux données formatées. Cela permet par exemple d'intégrer un fil Twitter à une page SharePoint, comme décrit ici.


Le problème est causé par les entités XML externes, qui n'étaient pas interdites dans les versions vulnérables. Cela permettait à n'importe quel utilisateur authentifié d'inclure le composant XML Web Part dans une page et de le configurer pour accéder en lecture (avec les droits du compte IIS AppPool) au système de fichiers.


Illustrons le problème avec une capture d'écran et quelques lignes de code. Le composant #2 se contente d'afficher des informations obtenues via "system-property", alors que le #1 (que nous allons détailler) exploite la vulnérabilité :




Côté XML, on définit un champ "doc" dont la valeur correspond à la variable "boom", c'est-à-dire au contenu du fichier déclaré dans le DTD :

<!DOCTYPE doc [
<!ENTITY boom SYSTEM "c:\\windows\\system32\\drivers\\etc\\hosts">
]>
<doc>&boom;</doc>

Et côté XSL, il suffit d'afficher la valeur du champ "doc" :

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
        <xsl:template match="/">
        <xsl:apply-templates/>
                <xsl:value-of select="doc"/>
        </xsl:template>
</xsl:stylesheet>

Les syntaxes "c:\\..." ainsi que "http://..." ou "file://..." fonctionnent.


Evidemment, le bug n'est pas limité aux seuls outils Microsoft. Les autres applications, qu'elles soient "maison" ou "sur étagère", peuvent elles aussi être impactées. Par exemple, DotNetNuke propose un module XML permettant d'afficher le résultat de transformations XSL. La version 06.00.00 de ce module corrige une vulnérabilité similaire à CVE-2011-1892 (d'ailleurs, le même PoC fonctionne). Pas d'advisory, pas de crédit, pas de mention explicite dans le ChangeLog :-( Merci DotNetNuke, je m'en souviendrais si je trouve d'autres vulns dans vos produits ...




Si on regarde le code-source de la version 04.03.05 du module XML de DotNetNUke, on y trouve une fonction XmlSource() (fichier "XmlController.vb") qui appelle XmlReader.Create() avec XmlReaderSettingsWithoutValidation() comme paramètre. Cette dernière fonction est définie comme suit dans "Utils.vbs" :

Dim settings As New XmlReaderSettings()
   settings.ProhibitDtd = False
   settings.ValidationType = ValidationType.None

La documentation Microsoft (System.Xml Security Considerations) est très claire :

XML data can include references to external resources such as a schema file. By default external
resources are resolved using an XmlUrlResolver object with no user credentials. This means that, by
default, you can access any locations that do not require credentials. You can secure this further by
doing one of the following:
- Restrict the resources that the XmlReader can access by setting the XmlReaderSettings::XmlResolver
property to an XmlSecureResolver object.
- Do not allow the XmlReader to open any external resources by setting the XmlReaderSettings::XmlResolver
property to null.

L'ajout à la fonction XmlReaderSettingsWithoutValidation() de la ligne "settings.XmlResolver = null" aurait du coup suffi à corriger le problème, mais les développeurs ont préféré passer à MSXML6, qui interdit par défaut l'utilisation de DTD et du coup bloque l'attaque.


Pour conclure :

  • les XEE ne sont pas morts, bien qu'ils aient été publiquement décrits il y a près de 10 ans. Rien que cette année, j'en ai trouvé 3 (Liferay, DotNetNuke, SharePoint) en analysant des wrappers autour de XSLT et Apple en a corrigé un dans servermgrd pour MacOS X Server. Sans oublier le papier de Kingcope (et oui, un XEE sous Java permet de lister le contenu des répertoires !)
  • même si l'impact se limite à une lecture de fichier, il existe de nombreux cas où cela peut suffire à compromettre pleinement une application, typiquement par obtention d'un fichier "web.config", "server.xml" ou équivalent

EDIT du 15 septembre 2011 à 14h20 : typos diverses, capture d'écran DotNetNuke, ...


Posté par Nicolas Grégoire | permalien | dans : vulnérabilités, xslt
Commentaires (1)

webmaster@agarri.fr
Copyright 2010-2014 Agarri

 Commentaires

Hello,

I tried to perform the attack within my sharepoint environment. Copy pasted the XML and XSL contents within respective parts of the XML editor, but when trying to apply, get a XSLT transform failure
(Failed to apply XSLT to the content)

Any clue why this is happening ?

Thanks

Posté par Fred le 20/09/2011 à 17h31

Ajouter un commentaire