Exploitation de CVE-2021-38297 : Vulnérabilité de dépassement de tampon dans GO Wasm

Présentation de la vulnérabilité

WebAssembly (WASM) est un format d'instructions binaires exécutable dans la plupart des navigateurs web modernes. Il sert de cible de compilation pour divers langages de haut niveau comme C, C++, Rust et GO, permettant d'écrire du code dans ces langages et de le compiler en WASM.

CVE-2021-38297 met en évidence un bug critique dans la compilation et le chargement par GO des binaires WASM compilés avec GO. La vulnérabilité réside dans le chargeur JS wasm (wasm_exec.js) fourni par GO, qui permet le chargement de binaires WASM avec des données illimitées dans l'argument argv. Étant donné que argv est stocké dans la mémoire linéaire de WASM, des acteurs malveillants pourraient exploiter cela pour écraser la mémoire linéaire du programme WASM compilé avec GO avec une entrée argv excessivement grande.

Cette vulnérabilité persistait dans les versions de GO antérieures à 1.17.2.

Application vulnérable : Vuln-Twitter

Cette preuve de concept présente une application de médias sociaux, Vuln-Twitter, permettant à plusieurs utilisateurs de publier du contenu et des commentaires. Le serveur web, construit sur Node.js, utilise SQLite pour stocker les données des publications et des commentaires.

Le front-end utilise du JS simple ainsi qu'un module GO WASM nommé wordprocessor.wasm. Ce module expose des méthodes comme toLeetSpeak, qui transforme les chaînes d'entrée en « LeetSpeak » (par exemple, « Hello! » devient « h3ll0! »).

Les modules GO WASM aident à afficher les publications et commentaires en LeetSpeak.

Exploitation du dépassement de tampon

Lors du processus de rendu front-end, lors de la réception des publications et commentaires du serveur, chaque commentaire est rendu en « LeetSpeak » à l'aide du module GO WASM. Le commentaire de chaque publication est passé comme partie de la variable argv après le chargement du module GO WASM.

De plus, il existe une méthode, processSharedVar(), dans le module GO, conçue pour lire la chaîne située à l'adresse 0x5000 et la convertir en discours simplifié (par exemple, « How are you? » devient « How r u? »). La publication originale est explicitement ajoutée à 0x5000 dans la mémoire linéaire pour être accessible par cette méthode, modifiant ainsi le contenu de la publication.

Reportez-vous à la section de code effectuant la même chose :

Diagramme de la mémoire linéaire WASM lors du rendu d'un commentaire :

Technique d'exploitation

En résumé :

1. Le front-end rend chaque publication et ses commentaires.
2. Lors du rendu, le module GO WASM se charge, traitant les commentaires via la variable argv et les publications à l'adresse mémoire 0x5000.
3. Les fonctions comme toLeetSpeak et processSharedVar sont utilisées respectivement pour le contenu des commentaires et des publications.

Compte tenu de l'absence de vérification de taille dans argv basée sur CVE-2021-38297, une menace potentielle apparaît. Si un utilisateur malveillant commente avec un commentaire surdimensionné sur une publication qui ne lui appartient pas, ce commentaire sera passé via argv lors du rendu. Comme il n'y a pas de limite de taille, le contenu à l'adresse 0x5000 (représentant la publication originale) devient susceptible d'être écrasé.

En exploitant cette faille, un utilisateur malveillant modifie efficacement le contenu de la publication originale, à l'instar d'une attaque XSS stockée. Par la suite, lorsque d'autres personnes consultent la page, le contenu modifié s'affiche, perpétué par la logique front-end partagée appliquée au rendu de chacun, ce qui entraîne la publication écrasée visible par tous.

Reproduction de l'exploit

Remarque : Pour reproduire cela, vous devez installer localement la version go go1.17.1, qui est la version vulnérable utilisée dans ce scénario. Vous pouvez vous référer à la documentation officielle de go sur la façon d'installer des versions spécifiques de go.

Essayons maintenant de reproduire le scénario ci-dessus :

1. Pour configurer l'ensemble de l'application, clonez d'abord le projet : git clone [email protected]:gkrishnan724/CVE-2021-38297.git && cd vuln-twitter
2. Exécutez npm install pour installer toutes les dépendances.
3. Exécutez npm run resetDB qui initialisera la base de données avec quelques publications et commentaires.
4. Exécutez npm run dev qui démarrera le serveur local, ouvrez localhost:3000 dans un navigateur et vous devriez voir une page de connexion.

Maintenant, connectons-nous avec un compte malveillant en utilisant les identifiants nom d'utilisateur : I_CANT_HACK, mot de passe : hacker, une fois connecté, vous devriez voir le fil d'actualité avec quelques publications.

Cette publication semble assez intéressante :

Amazon: ready 4 black friday? https://www.amazon.com/blackfriday

Et si, en utilisant la technique ci-dessus, nous pouvions écraser la publication d'Amazon.com pour pointer vers un lien malveillant ?

Référez-vous au fichier exploit.txt, il contient le commentaire rempli de remplissage de « A » de sorte que nous écrasions tout jusqu'à l'adresse 0x5000, à la fin vous pouvez voir le texte ready for black friday? https://evil.com/blackfriday. Si nous copions ce texte et commentons sur la publication ci-dessus, nous devrions pouvoir écraser la publication originale avec le texte ci-dessus.

Essayez par vous-même et voyez :)

Correction

Dans cette application, j'ai également fourni un script de correctif. Celui-ci utilise une version plus récente de go :

1. Exécutez la cible npm run patchServer

Cela devrait recompiler le fichier go avec la nouvelle version et démarrer le serveur avec la version corrigée.

Vous devriez maintenant remarquer que la publication n'est pas écrasée et si vous observez la console, nous voyons plutôt une erreur « Argument length too long ».

Conclusion

Nous avons démontré un scénario où l'exploitation d'un dépassement de tampon WASM sur la mémoire linéaire nous a permis d'exécuter une attaque XSS stockée. Cependant, il est essentiel de noter la spécificité de cet exploit : il nécessitait de manipuler un texte à une adresse codée en dur dans la mémoire linéaire. Dans les applications web pratiques, découvrir de telles vulnérabilités peut être extrêmement difficile en raison de ce niveau de spécificité. De plus, écraser des données arbitraires dans la mémoire linéaire sans provoquer un crash du système est complexe, en particulier lorsqu'il s'agit des modules et données internes de GO, principalement en raison du manque de documentation complète sur la disposition mémoire de GO.

D'après notre compréhension, nous pensons que la disposition mémoire linéaire de GO est représentée ci-dessous :