Exécution de code à partir de WinRAR – Compléments

Une vulnérabilité majeure ancienne de 19 ans a récemment été découverte par les équipes de Check Point Research dans l’application Web WinRAR. Celle-ci pouvait potentiellement mettre en danger plus de 500 millions d’utilisateurs.

Tribune Check point, étude de Nadav Grossman – La faille consistait simplement à extraire une archive d’un fichier « ACE » en apparence sans danger, ce qui pourtant peut conduire à une exécution de code à distance.

Dans cet article, nous expliquons comment nous avons découvert un bug logique à l’aide de l’outil de fuzzing WinAFL dans WinRAR (et dans d’autres programmes). La vulnérabilité est exploitée par simple extraction d’une archive. Elle affecte potentiellement 500 millions d’utilisateurs.

« Nadav Grossman de Check Point Software Technologies nous a informé d’une faille de sécurité dans la bibliothèque UNACEV2.DLL. La vulnérabilité susmentionnée permet de créer des fichiers dans des répertoires arbitraires à l’intérieur ou à l’extérieur du répertoire de destination lors de la décompression d’archives ACE. WinRAR utilise cette bibliothèque tierce pour décompresser les archives ACE. UNACEV2.DLL n’avait pas été mis à jour depuis 2005 et nous n’avons pas accès à son code source. Nous avons donc décidé de ne plus prendre en charge le format d’archive ACE pour protéger les utilisateurs de WinRAR. Nous remercions Check Point Software Technologies de nous avoir signalé ce problème. » explique-t-on sur le site de WinRAR.

Contexte

Il y a de cela quelques mois, notre équipe a mis en place un laboratoire de fuzzing multiprocesseurs, et nous avons commencé à tester des fichiers binaires dans les environnements Windows à l'aide de l’outil de fuzzing WinAFL. Après avoir obtenu de bons résultats dans le cadre de nos études sur les produits Adobe, nous avons décidé d’étendre nos tests, notamment à WinRAR.

Un des plantages produits par l’outil de fuzzing nous a conduit à une ancienne DLL, compilée en 2006 sans aucun mécanisme de protection (tels qu’ASLR, DEP, etc.) et utilisée par WinRAR (et d’autres logiciels). Nous nous sommes concentrés sur cette DLL avec l’intention de trouver un bug de corruption de mémoire qui, nous l’espérions, conduirait à une exécution de code à distance.

Cependant, l’outil de fuzzing a produit un cas de test avec un comportement étrange. L’étude de ce comportement nous a permis de découvrir un bug logique de traversée de répertoire. À partir de là, l’exploitation de cette vulnérabilité pour exécuter du code à distance était chose simple.

Qu’est-ce que WinRAR ?

WinRAR est un utilitaire d’archivage de fichiers pour Windows en version d’évaluation. Il crée des archives aux formats de fichiers RAR ou ZIP, en affiche le contenu, et décompresse de nombreux formats de fichiers d’archives.

« Plus de 500 millions d’utilisateurs dans le monde font de WinRAR l’outil de compression le plus populaire au monde » Citation du site web WinRAR.

Interface graphique de l’outil :

Processus de fuzzing

Voici les étapes utilisées pour tester WinRAR :

1. Ajout d’accroches à l’intérieur de la fonction principale de WinRAR pour nous permettre de traiter n’importe quel type d’archive, sans recourir à des accroches spécifiques pour chaque format, en modifiant l’exécutable WinRAR.
2. Élimination des éléments de l’interface graphique, tels que les messages et les boîtes de dialogue, qui nécessitent une interaction avec l’utilisateur, en modifiant l’exécutable WinRAR. Certains messages apparaissent même dans WinRAR en mode CLI.
3. Utilisation d’un corpus géant tiré d’une étude intéressante menée en 2005 par l’Université d’Oulu, https://www.ee.oulu.fi/roles/ouspg/PROTOS_Test-Suite_c10-archive.
4. Test du programme avec WinAFL à l’aide de commutateurs de ligne de commande qui forcent WinRAR à analyser « l’archive endommagée » et définir le mot de passe par défaut (« -p » pour le mot de passe, et « -kb » et « -inul » pour conserver les fichiers endommagés extraits), trouvés dans le manuel de WinRAR.

Nous avons constaté plusieurs plantages au bout d’une courte période de test, lors de l’extraction de plusieurs formats d’archive tels que RAR, LZH et ACE, causés par une vulnérabilité de corruption de mémoire (écriture hors limites). L’exploitation de ces vulnérabilités n’est pas anodine, car les primitives permettent un certain contrôle sur le tampon écrasé.

Un plantage lié à l’analyse du format ACE a cependant attiré notre attention. Nous avons constaté que WinRAR utilise une DLL nommée « unacev2.dll » pour l’analyse des archives ACE, et un rapide coup d’œil à cette DLL a révélé qu’il s’agit d’une ancienne DLL compilée en 2006 sans mécanisme de protection (tel qu’ASLR, DEP, etc.). Nous n’avons même pas eu besoin de contourner de protection.

Créer une accroche spécifique

Nous avons décidé de nous concentrer sur cette DLL car elle semblait prometteuse pour notre étude. Afin d’améliorer les performances de nos tests et couvrir uniquement cette DLL, nous avons ajouté une accroche spécifique à « unacev2.dll ».

Pour ce faire, nous devions comprendre comment cette dernière est utilisée. Après avoir désassemblé le code appelant « unacev2.dll » pour l’extraction d’archives au format ACE, nous avons constaté que deux fonctions exportées doivent être appelées pour l’extraction dans l’ordre suivant :

1. Une fonction d’initialisation nommée « ACEInitDll », avec la signature suivante : INT __stdcall ACEInitDll(structure_inconnue_1 *struct_1);
   – struct_1 : pointeur sur une structure inconnue
2. Une fonction d’extraction nommée « ACEExtract », avec la signature suivante : INT __stdcall ACEExtract(LPSTR NomArchive, structure_inconnue_2 *struct_2);
   – NomArchive : pointeur sur le chemin d’accès du fichier ACE à extraire
   – struct_2 : pointeur sur une structure inconnue

Ces deux fonctions nécessitent des structures qui nous sont inconnues. Nous avions deux options pour tenter de les comprendre : désassembler et déboguer WinRAR, ou essayer de trouver un projet open source utilisant ces structures.

La première option prenant plus de temps, nous avons donc tenté la seconde en recherchant la fonction exportée « ACEInitDll » sur github.com. Nous avons trouvé le projet FarManager qui utilise cette DLL et inclut un fichier d’en-tête détaillé pour les structures inconnues (le créateur de ce projet est le créateur de WinRAR).

Après avoir chargé les fichiers d’en-tête dans un désassembleur d’interface, il était beaucoup plus facile de comprendre les « structures inconnues » transmises aux deux fonctions (ACEInitDll et ACEExtract), car elles n’étaient plus « inconnues » : le désassembleur affichait le bon nom et le bon type pour les membres de chaque structure.

Parmi les en-têtes du projet FarManager, nous avons trouvé la signature suivante :

INT __stdcall ACEInitDll(pACEInitDllStruc DllData);
INT __stdcall ACEExtract(LPSTR NomArchive, pACEExtractStruc Extract);

Pour imiter la manière dont WinRAR utilise « unacev2.dll », nous avons affecté le même membre de structure comme dans WinRAR. Nous avons commencé à tester ces accroches spécifiques, mais nous n’avons trouvé aucun nouveau plantage, et la couverture n’étant pas élargie au cours des premières heures du test, nous avons donc essayé de comprendre la raison de cette limitation. Nous avons recherché des informations sur le format d’archive ACE.

Après avoir modifié toutes les vérifications de structure, tels que la validation de CRC, nous avons à nouveau activé notre outil de fuzzing. Au bout d’une courte période de fuzzing, nous sommes entrés dans le répertoire principal de fuzzing et avons trouvé quelque chose d’étrange. Mais voici tout d’abord les détails de notre machine de fuzzing.

Pour améliorer les performances de l’outil de fuzzing et éviter les goulots d’étranglement en entrée/sortie, nous avons utilisé un disque RAM via la boîte à outils ImDisk sur la machine à fuzzing.

Détection du bug de traversée de répertoire

Peu de temps après le lancement de l’outil de fuzzing, nous avons découvert un nouveau répertoire nommé « sourbe » à un emplacement surprenant, à la racine du lecteur R:\

Les accroches sont chargées d’extraire '’archive testée dans des sous-répertoires sous « répertoires_de_sortie », par exemple « R:\ACE_FUZZER\répertoires_de_sortie\Esclave_2\ », donc pourquoi avons-nous un nouveau répertoire dans le répertoire parent ? Dans le répertoire « sourbe », nous avons trouvé un fichier nommé « RED VERSION_¶ ».

Voici les 3 premiers éléments que nous avons remarqués dans la sortie en hexadécimal de acefile :

1. L'outil de fuzzing a copié des portions du champ de l’annonce dans d'autres champs :
   – Le contenu du fichier compressé est « SIO », indiqué dans un cadre orange dans la sortie en hexadécimal. Cela fait partie de la chaîne de l’annonce « *UNREGISTERED VERSION* »
   – Le champ nom du fichier contient la chaîne « RED VERSION* » qui fait également partie de la chaîne de l’annonce « *UNREGISTERED VERSION* »
2. Le chemin d’accès dans le champ nom de fichier a été utilisé dans le processus d’extraction comme « chemin d’accès absolu » au lieu d’un chemin d’accès relatif vers le répertoire de destination (la barre oblique inversée est la racine du lecteur).
3. Le nom du fichier extrait est « RED VERSION_¶ ». Il semble que l’astérisque du champ « nom de fichier » ait été converti en tiret de soulignement et la valeur \x14\ (0x14) est représentée par « ¶ » dans le nom du fichier extrait. L’autre contenu du champ « nom de fichier » est ignoré car le caractère null termine la chaîne, après la valeur \x14\ (0x14).

Afin de déterminer pourquoi le répertoire de destination a été ignoré et pourquoi le champ « nom de fichier » a été utilisé comme chemin d’accès absolu lors de l’extraction, nous avons fait plusieurs essais pour vérifier nos hypothèses. Notre première hypothèse était que le premier caractère du champ « nom de fichier » (le caractère « \ ») déclenche la vulnérabilité.

Malheureusement, après une rapide vérification, nous avons découvert que ce n’était pas le cas. Au bout de quelques vérifications supplémentaires, nous sommes arrivés à ces conclusions :

1. Le premier caractère devrait être un « / » ou un « \ »
2. « * » doit être inclus dans le nom du fichier au moins une fois, peu importe où

Exemple de champ de nom de fichier déclenchant le bug : « \répertoire\fichier*.exe » sera extrait dans « C:\répertoire\fichier_.exe » et l’astérisque est converti en tiret de soulignement (_). Maintenant que cela fonctionne avec nos accroches de fuzzing, il est temps de tester notre fichier d’archive spécialement conçu (par exemple, un fichier malveillant) avec WinRAR.

Test d’un fichier malveillant avec WinRAR

À première vue, l’exploitation de la vulnérabilité semblait avoir réussi dans WinRAR, car le répertoire « sourbe » a été créé à la racine du lecteur « C:\ ». Cependant, lorsque nous sommes entrés dans le répertoire « sourbe » (« C:\sourbe »), nous avons constaté que le fichier n’avait pas été créé. Ces comportements ont soulevé deux questions :

• Pourquoi WinRAR s’est-il comporté différemment des accroches ?
• Pourquoi les répertoires spécifiés dans le fichier malveillant ont été créés et le fichier extrait n’a pas été créé ?

Pourquoi WinRAR s’est-il comporté différemment des accroches ?

Nous nous attendions à ce que le fichier malveillant se comporte de la même manière dans WinRAR et nos accroches, pour les raisons suivantes :

1. La DLL (unacev2.dll) extrait les fichiers dans le répertoire de destination, et non l’exécutable externe (WinRAR ou nos accroches)
2. Nos accroches imitent parfaitement WinRAR lors du passage de paramètres/membres de structure à la DLL

Une analyse approfondie a montré que nous avions fait fausse route quant à notre second point. Nos accroches définissent 4 pointeurs de rappel, et les fonctions de rappel que nous avons mis en place diffèrent des fonctions de rappel de WinRAR. Revenons à notre implémentation des accroches. Nous avions mentionné cette signature lors de l’appel de la fonction exportée nommée « ACEInitDll ».

La fonction d’extraction dans « unacv2.dll » appelle StateCollblackProc dans WinRAR et transmet le champ du nom de fichier du format ACE en tant que chemin d’accès relatif pour l’extraction.

Le chemin d’accès relatif est vérifié par le validateur de la fonction de rappel de WinRAR, et le validateur communique ACE_CALLBACK_RETURN_CANCEL à la DLL (car le champ du nom de fichier commence par la barre oblique inversée « \ ») et la création du fichier est abandonnée.

La chaîne suivante est transmise au validateur de la fonction de rappel de WinRAR : « \sourbe\RED VERSION_¶ »

Remarque : il s’agit des champs de nom de fichier d’origine « \sourbe\RED VERSION*¶ », « unacev2.dll » remplace le « * » par un tiret de soulignement.

Pourquoi les répertoires spécifiés dans le fichier malveillant ont été créés et le fichier extrait n’a pas été créé ?

En raison d’un bug dans la DLL (unacev2.dll), même si ACE_CALLBACK_RETURN_CANCEL est communiqué par la fonction de rappel, les répertoires spécifiés dans le chemin d’accès relatif (champ nom de fichier dans l’archive ACE) sont créés par la DLL. La raison en est que « unacev2.dll » appelle le validateur externe (fonction de rappel) avant la création du répertoire, mais il vérifie la valeur communiquée par la fonction de rappel trop tard, après la création du répertoire, et abandonne l’opération d’extraction juste avant l’écriture du contenu dans le fichier extrait, avant l’appel de l’API WriteFile.

La DLL crée réellement le fichier extrait, mais sans y écrire de contenu, simplement par appel de l’API CreateFile, puis le code de retour de la fonction de rappel est vérifié. Si le code de retour est ACE_CALLBACK_RETURN_CANCEL, le fichier créé précédemment par l’appel de l’API CreatFile est supprimé.

Remarque :

• Nous avons trouvé un moyen de contourner la suppression du fichier, mais cela nous permet de créer uniquement des fichiers vides. Nous contournons la suppression de fichier en ajoutant « : » à la fin du fichier, qui est traité comme étant un flux de données alternatif. Si la fonction de rappel communique « ACE_CALLBACK_RETURN_CANCEL », « unacev2.dll » essaie de supprimer le flux de données alternatif du fichier au lieu du fichier lui-même.
• Une autre fonction de filtrage est présente dans le code de « unacev2.dll » qui interrompt l’opération d’extraction si la chaîne de chemin d’accès relatif commence par 15 « \ » (barre oblique). Cela se produit durant les premières étapes d’extraction, avant les appels à une autre fonction de filtrage.
• Cependant, en ajoutant les caractères « * » ou « ? » (caractères joker) au chemin d’accès relatif (champ du nom de fichier) du fichier compressé, cette vérification est ignorée, et le flux de code peut se poursuivre pour déclencher (partiellement) la vulnérabilité de traversée de répertoire. C’est pourquoi le fichier malveillant produit par l’outil de fuzzing a déclenché le bug dans nos accroches (cela ne déclenche pas le bug dans WinRAR en raison du validateur de la fonction de rappel dans le code WinRAR).

Résumé des résultats intermédiaires

• Nous avons découvert une vulnérabilité de type traversée de répertoire dans « unacev2.dll ». Elle permet à nos accroches d’extraire un fichier sur un chemin d’accès arbitraire, d’ignorer complètement le répertoire de destination et de traiter le chemin d’accès relatif du fichier extrait comme un chemin d’accès complet. Deux contraintes mènent à la vulnérabilité de traversée de répertoire (résumée dans les sections précédentes) :
  1. Le premier caractère devrait être un « / » ou un « \ »,
  2. « * » doit être inclus dans le nom du fichier au moins une fois, peu importe où, WinRAR est partiellement exposé à une vulnérabilité de traversée de répertoire
• « unacev2.dll » n’interrompt pas l’opération après que la fonction de rappel de WinRAR lui ait communiqué le code d’abandon (ACE_CALLBACK_RETURN_CANCEL). En raison de cette vérification retardée du code communiqué par la fonction de rappel de WinRAR, les répertoires spécifiés dans le fichier malveillant sont créés.
• Le fichier extrait est également créé, sur le chemin d’accès complet spécifié dans le fichier malveillant (sans contenu), mais il est supprimé immédiatement après vérification du code communiqué par la fonction de rappel (avant l’appel à l’API WriteFile).
• Nous avons trouvé un moyen d’éviter la suppression du fichier, mais cela nous permet de ne créer que des fichiers vides.

Détermination de la cause profonde

À ce stade, nous voulions comprendre pourquoi le répertoire de destination est ignoré et pourquoi le chemin d’accès relatif des fichiers d’archive (champ « nom de fichier ») est traité comme un chemin d’accès complet. Pour atteindre cet objectif, nous pouvions utiliser l’analyse statique et le débogage, mais avons préféré utiliser une méthode beaucoup plus rapide. Nous avons utilisé DynamoRio pour enregistrer la couverture d’un fichier ACE normal par le code de « unacev2.dll », et de notre fichier malveillant qui a déclenché le bug. Nous avons ensuite utilisé le plugin lighthouse pour 16
notre désassembleur d’interface et avons soustrait la couverture d’un des chemins d’accès de l’autre.

D’après les résultats de la couverture du code, on peut voir que le fichier malveillant ne passe pas par le bloc de base différencié (indiqué en bleu), mais par le bloc de base opposé (la condition Faux, indiquée par une flèche rouge). Si le flux de code passe par la condition Faux (flèche rouge), la ligne indiquée par le cadre vert remplace le répertoire de destination par «  » (chaîne vide) et l’appel suivant à la fonction sprintf, qui concatène le répertoire de destination avec le chemin d’accès relatif du fichier extrait.

Le flux de code vers les conditions Vrai et Faux, indiquées par les flèches verte et rouge, est influencé par l’appel de la fonction « GetDevicePathLen » (indiquée dans un cadre rouge). Si le résultat de l’appel à GetDevicePathLen est égal à 0, la fonction sprintf sera : sprintf (chemin_fichier_final, "%s%s", répertoire_destination, chemin_relatif_fichier);

Autrement : sprintf(chemin_fichier_final, "%s%s", "", chemin_relatif_fichier); La dernière fonction sprintf est le code du bug qui déclenche la vulnérabilité de traversée de répertoire. Cela signifie que le chemin d’accès relatif sera en réalité traité comme un chemin d’accès complet vers le fichier/répertoire à créer.

Le chemin d’accès relatif du fichier extrait est passé en paramètre à GetDevicePathLen. La fonction vérifie si le préfixe du nom de lecteur apparaît dans le paramètre du chemin et renvoie la longueur de cette chaîne.

Si la valeur renvoyée par GetDevicePathLen est supérieure à 0, comme dans les exemples ci-dessus à l’exception du dernier, le chemin d’accès relatif du fichier extrait sera considéré comme étant un chemin d’accès complet, car le répertoire de destination est remplacé dans ce cas par une chaîne vide lors de l’appel à sprintf. Cela conduit à la vulnérabilité de traversée de répertoire.

Il existe cependant une fonction qui « nettoie » le chemin d’accès relatif du fichier extrait, en omettant les séquences non autorisées avant GetDevicePathLen. La fonction omet les séquences superficielles de traversée de répertoire telles que « ..\ », et omet la séquence du lecteur, telle que : « c:\ », « c: » Et pour une raison inconnue : « c:\c: » également. Notez que la première lettre n’a pas d’importance. La séquence suivante sera également omise : « _:\ », « _: », « _:\_: » (dans ce cas, le tiret de soulignement représente n’importe quelle valeur).

Concrétisation du bug

Pour créer un fichier malveillant, provoquant l’extraction depuis WinRAR d’un fichier archivé vers un chemin d’accès arbitraire (traversée de répertoire), par exemple le répertoire Démarrage (qui permet une exécution du code après redémarrage) au lieu du répertoire de destination, nous devons contourner deux filtres et déclencher le bug. Il déclenchera la concaténation d’une chaîne vide pour le chemin d’accès relatif du fichier compressé, au lieu du répertoire de destination, tel que :

sprintf (chemin_d_accès_final, "%s%s", "", chemin_d_accès_relatif);

Au lieu de :

sprintf(chemin_d_accès_final, "%s%s",répertoire_de_destination, chemin_d_accès_relatif);

Le résultat de la fonction GetDevicePathLen doit être supérieur à 0. Il dépend du contenu du chemin d’accès relatif (« chemin_d_accès_relatif ») si le chemin d’accès relatif commence par un chemin d’accès à un lecteur tel que :

• Option 1 : « C:\répertoire\fichier.ext »
• Option 2 : « \répertoire\fichier.ext » (la première barre oblique représente le lecteur actuel)

La valeur renvoyée par GetDevicePathLen sera supérieure à 0. Il existe cependant une fonction de filtrage nommée CleanPath (Figure 17) dans « unacev2.dll » qui vérifie si le chemin d’accès relatif commence par « C:\ » et le supprimer de la chaîne du chemin d’accès relatif avant l’appel à GetDevicePathLen.

Elle omet la séquence « C:\ » de la chaîne Option 1 mais n’omet pas la séquence « \ » de la chaîne Option 2.

Pour surmonter cette limitation, nous pouvons ajouter une autre séquence « C:\ » à Option 1 qui sera omise par CleanPath (Figure 17), et laissera le chemin d’accès relatif « C:\ » dans la chaîne comme nous le souhaitions :
– Option 1’ : « C:\C:\répertoire\fichier.ext » => « C:\répertoire\fichier.ext »

Le code WinRAR (Figure 13) comporte également une fonction de rappel utilisée comme fonction de validation/filtrage. Au cours du processus d’extraction, « unacev2.dll » appelle la fonction de rappel qui réside dans le code WinRAR. La fonction de rappel valide le chemin d’accès relatif du fichier compressé. S’il comporte une séquence en liste noire, l’opération d’extraction est annulée. L’une des vérifications effectuées par la fonction de rappel concerne le chemin d’accès relatif commençant par «\ » (barre oblique). La fonction ne recherche pas la présence de « C:\ », par conséquent, nous pouvons utiliser Option 1 pour exploiter la vulnérabilité de traversée de répertoire ! Nous avons également trouvé un vecteur d’attaque SMB qui permet de se connecter à une adresse IP quelconque et créer des fichiers et des répertoires de manière arbitraire sur le serveur SMB.

Exemple :

« C:\\\10.10.10.10\nom_de_répertoire_smb\répertoire\fichier.ext » =>
« \\10.10.10.10\nom_de_répertoire_smb\répertoire\fichier.ext »

Exemple de fichier malveillant simple

Nous changeons l’extension « .ace » en « .rar », car WinRAR détecte le format par le contenu du fichier et non par son extension. Nous déclenchons la vulnérabilité par la chaîne spécialement conçue du champ nom de fichier.

Cette archive sera extraite dans « c:\répertoire\fichier.txt », quel que soit le chemin d’accès du répertoire de destination.

Création d’une véritable exploitation de la vulnérabilité

Nous pouvons obtenir une exécution de code par extraction d’un fichier exécutable compressé depuis l’archive ACE vers un répertoire Démarrage. Tous les fichiers présents dans un répertoire Démarrage sont exécutés au moment du démarrage de Windows. La création d’une archive ACE qui extrait ses fichiers compressés dans un répertoire de démarrage semble cependant être une tâche triviale. Ce n’est pourtant pas le cas.

Il existe au moins 2 répertoires Démarrage avec les chemins d’accès suivants :

1. C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp
2. C:\Utilisateurs\<nom d’utilisateur>\AppData\Roaming\Microsoft\Windows\Menu Démarrer\Programmes\Démarrage

Le premier chemin d’accès du répertoire Démarrage requiert des privilèges élevés/un niveau d’intégrité élevé (si le contrôle de compte utilisateur est activé). WinRAR est exécuté par défaut avec un niveau d’intégrité moyen. Le second chemin d’accès du répertoire Démarrage nécessite de connaître le nom de l’utilisateur.

Nous pouvons essayer de contourner cette difficulté en créant une archive ACE contenant des milliers de fichiers compressés spécialement conçus, et contenant le chemin d’accès au répertoire Démarrage mais avec différents noms d’utilisateur en espérant que cela fonctionnera auprès de notre cible.

Le vecteur le plus puissant

Nous avons trouvé un vecteur qui nous permet d’extraire un fichier dans le répertoire Démarrage sans nous soucier du nom d’utilisateur. En utilisant le champ de nom de fichier suivant dans l’archive ACE : « C:\C:C:..\AppData\Roaming\Microsoft\Windows\Menu Démarrage\Programmes\Démarrage\fichier.exe » La fonction CleanPath le traduit dans le chemin suivant : « C:..\AppData\Roaming\Microsoft\Windows\Menu Démarrer\Programmes\Démarrage\fichier.exe » Car la fonction CleanPath supprime la séquence « C:\C: ».

Ce répertoire de destination sera de plus ignoré car la fonction GetDevicePathLen renverra 2 pour la dernière séquence « C: ».

Analyse du dernier chemin d’accès :

La séquence « C: » traduite par Windows en « répertoire actuel » du processus en cours d’exécution est dans notre cas le chemin d’accès actuel de WinRAR. Dans le cas où WinRAR est exécuté à partir de son répertoire, le « répertoire actuel » sera le répertoire WinRAR, « C:\Program Files\WinRAR » Cependant, si WinRAR est exécuté en double-cliquant sur un fichier d’archive ou en cliquant sur extraire en faisant un clic droit sur le fichier d’archive, le « répertoire actuel » de WinRAR sera le chemin d’accès du répertoire dans lequel se trouve l’archive.

Si l’archive se trouve par exemple dans le répertoire Téléchargements de l’utilisateur, le « répertoire actuel » de WinRAR sera « C:\Utilisateurs\<nom d’utilisateur>\Téléchargements » ou si l’archive se trouve sur le bureau, le chemin d’accès du répertoire actuel sera « C:\Utilisateurs\<nom d’utilisateur>\Bureau ».

Pour passer du répertoire Bureau ou Téléchargements au répertoire Démarrage, nous devons remonter d’un répertoire « ..\ » au « répertoire de l’utilisateur » et concaténer dans la séquence suivante « c:..\ » le chemin d’accès relatif du répertoire. Le répertoire Démarrage « AppData\Roaming\Microsoft\Windows\Menu Démarrer\Programmes\Démarrage\ » Par conséquent, « C:..\AppData\Roaming\Microsoft\Windows\Menu Démarrer\Programmes\Démarrage\fichier.exe »

Je vous rappelle qu’il existe 2 vérifications des séquences empêchant la traversée de répertoire : une dans la fonction CleanPath qui ignore ces séquences et une dans la fonction de rappel de WinRAR qui annule l’opération d’extraction. CleanPath recherche le schéma suivant de traversée de répertoire : « \..\ » La fonction de rappel de WinRAR recherche la présence des schémas suivants :

a. « \..\ »
b. « \../ »

Puisque la barre oblique ou la barre oblique inverse ne fait pas partie de notre séquence « C:../ », nous pouvons contourner la validation de la traversée de répertoire. Nous ne pouvons cependant remonter qu’à un seul niveau de répertoire et c’est tout ce dont nous avons besoin pour extraire un fichier dans le répertoire Démarrage sans avoir besoin de connaître le nom d’utilisateur.

Remarque : si nous voulons remonter de plusieurs répertoires, nous devons concaténer la séquence suivante « /../ », par exemple « C:../../ ». La séquence « /../ » sera capturée par le validateur de la fonction de rappel et l’extraction sera annulée.

Vers la fin de l’étude, nous avons découvert que WinACE possédait un utilitaire d’extraction pour Linux appelé « unace-nonfree » (compilé à l’aide du compilateur Watcom) et ressemblant à « unacev2.dll ». Son code source est disponible. Le code source pour Windows (qui a servi au développement de « unacev2.dll ») ou au moins une portion est également inclus, mais il est plus ancien que la dernière version de « unacev2.dll » et ne peut être compilé pour Windows. Certaines fonctionnalités manquent dans le code source, par exemple, les vérifications de la Figure 17 ne sont pas incluses. La Figure 16 est cependant extraite à partir du code source. Le bug de traversée de répertoire est également présent dans le code source.

Autre remarque intéressante, Zerodium a proposé 100 000 dollars pour une telle vulnérabilité en octobre 2018.

Réponse de WinRAR :

WinRAR a décidé de supprimer « unacev2.dll » de son package et WinRAR ne prend plus en charge le format ACE à partir de la version 5.70 beta 1

Citation du site web WinRAR :

« Nadav Grossman de Check Point Software Technologies nous a informé d’une faille de sécurité dans la bibliothèque UNACEV2.DLL. La vulnérabilité susmentionnée permet de créer des fichiers dans des répertoires arbitraires à l’intérieur ou à l’extérieur du répertoire de destination lors de la décompression d’archives ACE. WinRAR utilise cette bibliothèque tierce pour décompresser les archives ACE. UNACEV2.DLL n’avait pas été mis à jour depuis 2005 et nous n’avons pas accès à son code source. Nous avons donc décidé de ne plus prendre en charge le format d’archive ACE pour protéger les utilisateurs de WinRAR. Nous remercions Check Point Software Technologies de nous avoir signalé ce problème. »