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 :
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 :