Adobe Reader et XSLT

1. Démarche globale

Cela fait plusieurs années que j’applique une démarche relativement atypique pour identifier des vulnérabilités dans certains logiciels du marché. L’astuce consiste à tester de manière isolée un composant open source, en utilisant l’ensemble des solutions techniques applicables (calcul de la couverture de code avec GCov [GCOV], instrumentation des accès mémoire avec Address Sanitizer [ASAN], visualisation de structures complexes avec Data Display Debugger [DDD]…). Une fois une ou plusieurs vulnérabilités identifiées, il ne reste qu’à les déclencher via le logiciel ciblé, qui lui est éventuellement propriétaire.

Cette technique a permis d’identifier des vulnérabilités dans VMware ESX, Novell eDirectory, Webkit, PostgreSQL, PHP5 et Adobe Reader. Évidemment, cette technique permet entre autres de réaliser du fuzzing très ciblé, avec des performances très largement supérieures à celles pouvant être obtenues en testant le logiciel de manière globale.

2. Adobe Reader et Sablotron

Dans le cas d’Adobe Reader, il est possible d’exécuter du code XSLT soit via les formulaires XFA (« XML Forms Architecture » [XFA]), soit via JavaScript. La création de formulaires XFA+XSLT nécessitant l’utilisation d’Adobe LiveCycle ES3, l’option JavaScript a été privilégiée.

Une structure modulaire est adoptée pour le fichier PDF de test : le code JavaScript traite des documents XML (la source de données et la feuille XSLT) localisés ailleurs dans le document, ici en xfa.data.nodes.item(0). La source de données XML est le premier nœud, et la feuille XSLT le deuxième. Le résultat de la transformation est affiché via une boîte de dialogue :

Les interpréteurs XSLT disposent tous de fonctions d’introspection. Cela permet d’identifier facilement l’interpréteur sous-jacent, simplement en appelant la fonction system-property(’xsl:vendor’). Lors de la phase d’identification de l’interpréteur XSLT sous-jacent, la feuille XSLT suivante est utilisée :

Le résultat, illustré par la capture d’écran suivante, est identique pour toutes les versions d’Adobe Reader.

 

 

L’URL www.gingerall.com révèle que l’interpréteur XSLT utilisé est Sablotron. Pour être plus précis, Ginger Alliance était l’hébergeur et le principal contributeur de Sablotron, à l’époque où ce projet était encore actif. De nos jours, il n’existe plus qu’une page sur [SOURCEFORGE] référençant la dernière version (1.0.3 datée de juillet 2006). Une recherche pour le mot-clé Sablotron sur le site d’Adobe révèle que les modifications apportées par Adobe à cette bibliothèque sont librement téléchargeables depuis leur site [PATCH]. Les modifications les plus récentes datent de 2004 et s’appliquent à Sablotron 1.0.1, que nous allons donc tester.

Récapitulons… Adobe Reader inclut une version modifiée d’une bibliothèque open source, Sablotron. La version sur laquelle se base Adobe est vieille d’une dizaine d’années, et les fichiers CHANGES indiquent qu’une attention spécifique a été portée aux aspects de performance et de sécurité :

Voilà un challenge qui s’annonce intéressant !

3. Instrumentation et fuzzing de Sablotron

Address Sanitizer est un des modules du compilateur LLVM. Il permet d’étudier de manière dynamique (pendant l’exécution d’un programme) les accès à la mémoire, afin de détecter des erreurs comme des « heap overflow » ou « double free ». Les performances d’un programme compilé avec Address Sanitizer sont deux fois moins bonnes que sans instrumentation. Cela reste extrêmement intéressant comparé à Valgrind dont l’impact est d’un facteur 20 à 30. La compilation de Sablotron 1.0.1 avec LLVM et Address Sanitizer est triviale :

Nous disposons maintenant d’un exécutable minimaliste, instrumenté et représentatif des fonctionnalités XSLT d’Adobe Reader. Il ne reste plus qu’à appliquer un fuzzing par mutation tout à fait classique. Or, qui dit fuzzing par mutation (ou dumb fuzzing) implique l’accès à un volumineux corpus de feuilles XSLT valides et l’utilisation d’un diversificateur adapté à ce format.

Ayant par le passé eu pas mal de succès avec Radamsa [RADAMSA] (dont l’identification de failles de sécurité dans Microsoft Excel, Mozilla Firefox, Webkit, …), la question du diversificateur ne se pose pas. En ce qui concerne l’obtention de multiples feuilles XSLT valides, il suffit d’utiliser les « Test Suites » éditées par le W3C, le NIST ou OASIS. Les interfaces de suivi de bugs de plusieurs projets libres ont elles aussi été écumées, afin de collecter des feuilles XSLT connues pour avoir causé des problèmes.

Le banc de tests est donc composé des binaires Sablotron et Radamsa, d’une source de données XML relativement complexe, de 7 000 feuilles XSLT distinctes et d’un simple script Shell orchestrant le tout. Environ deux millions de tests sont réalisés chaque jour, dans une VM hébergée sur un ordinateur portable. Cela est bien supérieur à ce qu’il serait possible d’obtenir en testant directement Adobe Reader.

4. CVE-2012-1525 : débordement sur le tas

Au bout de quelques minutes, un premier plantage est détecté par ASan. Le rapport généré est le suivant :

Comme toujours avec ASan, le rapport est très riche et permet d’appréhender rapidement le bug. Ici, une structure de 1400 octets est allouée via l’opérateur new[] dans la fonction isValidNCName(). Un peu plus tard, la fonction utf8ToUtf16() tente d’écrire après cette structure, indiquant un débordement sur le tas tout à fait classique.

Voici le code de la fonction qui vérifie la validité du NCName passé en paramètre :

La structure buff est créée ligne 356 avec une taille issue de la fonction utf8StrLength(). Le code de cette fonction est le suivant :

Il apparaît que la variable len n’est mise à jour que par len++ dans l’instruction for. Donc, le résultat de utf8SingleCharLength() n’affectera pas sa valeur. Cette fonction retournera donc 5 pour la chaîne AB, au lieu de 8 (4 caractères de 1 octet + 1 caractère de 4 octets). La variable buff sera donc trop petite pour stocker le résultat de la conversion, d’où le crash ligne 169 (dans le cas présent) de la fonction utf8ToUtf16() détaillée ci-dessous :

Une feuille XSLT minimaliste permettant de reproduire le bug serait de la forme suivante :

Une fois notre fichier PDF de test modifié pour inclure cette feuille XSLT, il suffit de l’ouvrir dans Adobe Reader pour déclencher le bug. Voilà ce que cela donne avec Reader 9.5.1 sous Linux :

En termes d’exploitation, les contraintes sont peu nombreuses : l’attaquant peut allouer une variable de la taille qu’il souhaite, puis y copier des données dont il maîtrise la longueur et le contenu ;-)

5. CVE-2012-1530 : confusion de type

Un deuxième plantage est détecté quelques jours plus tard. Le rapport est cette fois-ci moins précis, cette famille de vulnérabilités (confusion de type) n’étant pas de celles détectées nativement par ASan :

Le programme plante en essayant d’accéder l’adresse 0x74757074756f lors de l’appel à la méthode getName de la structure « a » de type « Attribute ». Or cette valeur ressemble étrangement à une chaîne ASCII. Après décodage, cette valeur correspond à la chaîne output qui est bel et bien présente dans la source de données XML. Après réduction manuelle de la feuille XSLT et des données XML, nous arrivons à quelque chose d’intéressant.

La feuille XSLT :

La source de données XML :

Le crash :

Il reste une question à laquelle répondre : comment les données injectées par l’attaquant sont-elles utilisées par la suite par le programme ? Regardons avec GDB :

Récapitulons : suite à des conversions de type explicites causées par les appels à la fonction XPath node(), une chaîne de texte extraite de la source de données XML est utilisée comme adresse mémoire. Cette adresse mémoire est considérée par l’application comme une structure de type « Attribute ». Cette structure contient à l’offset 0x40 un pointeur vers la fonction getName qui est exécutée directement après. Voici une situation parfaite pour l’attaquant !

Vérifions tout de même si le fonctionnement est similaire sous Adobe Reader (ici la version 10.1.4 sous Windows) :

 

 

Impeccable ! Mis à part de légères différences liées au changement de système d’exploitation, de plate-forme matérielle et de compilateur, on retrouve bien le comportement identifié dans la version « ligne de commandes ». Maîtriser le pointeur d’exécution est maintenant trivial, et l’exploitation complète est laissée en exercice au lecteur. Il est à noter que les versions X et XI d’Adobe Reader incluent un « bac à sable », dont il faudra ensuite sortir… ou pas.

Conclusion

Voilà comment l’étude d’une obscure bibliothèque permet d’identifier facilement plusieurs vulnérabilités affectant toutes les versions d’Adobe Reader. La même méthodologie est applicable aux autres bibliothèques utilisées par Adobe Reader, et bien sûr à tous les programmes propriétaires incluant des composants open source. Bonne chasse !

Liens

[GCOV] http://en.wikipedia.org/wiki/Gcov

[ASAN] http://code.google.com/p/address-sanitizer/

[DDD] http://www.gnu.org/software/ddd/

[XFA] http://partners.adobe.com/public/developer/xml/index_arch.html

[SOURCEFORGE] http://sourceforge.net/projects/sablotron/

[PATCH] http://partners.adobe.com/public/developer/opensource/index.html

[RADAMSA] http://code.google.com/p/ouspg/wiki/Radamsa