Corruption de mémoire dans WebAssembly : exploits natifs à l’intérieur

Introduction : Quand le code natif rencontre le Web

WebAssembly (WASM) a révolutionné le développement web en permettant des performances proches du natif dans les navigateurs. Les développeurs peuvent désormais compiler C, C++, Rust et d’autres langages en un format binaire portable qui s’exécute à des vitesses remarquables. Cependant, cette avancée technologique a involontairement ouvert une boîte de Pandore de défis de sécurité — ramenant des vulnérabilités de corruption mémoire vieilles de plusieurs décennies des plateformes natives directement dans l’environnement du navigateur.

La promesse de WebAssembly est séduisante : des applications critiques en performance s’exécutant sans couture dans les navigateurs web, sans plugins ni installations natives. Pourtant, derrière cette innovation se cache une réalité sombre : les vulnérabilités classiques de sécurité mémoire comme les débordements de tampon et les bugs use-after-free sont toujours présentes dans les modules WebAssembly, créant une nouvelle frontière pour l’exploitation dans le navigateur.

Comprendre le modèle de mémoire de WebAssembly

Mémoire linéaire : une arme à double tranchant

Le modèle de mémoire linéaire de WebAssembly utilise un espace d’adressage contigu unique pour organiser la mémoire, permettant à l’unité de traitement d’accéder directement et séquentiellement aux emplacements mémoire. Bien que cette conception offre des performances exceptionnelles, elle introduit aussi des risques de sécurité importants lorsque les modules accèdent à la mémoire en dehors de leurs plages allouées.

Contrairement à l’environnement mémoire géré de JavaScript, WebAssembly donne aux développeurs un contrôle bas niveau sur l’allocation et la manipulation de la mémoire. Les variables en C/C++ peuvent être traduites en deux primitives différentes dans WebAssembly : les variables locales avec une portée fixe stockées dans l’espace d’index, et les variables locales avec une portée statique peu claire stockées dans une pile séparée accessible par l’utilisateur dans la mémoire linéaire. Cette décision architecturale crée des opportunités pour que des vulnérabilités classiques de corruption mémoire se manifestent.

La lacune du compilateur : absence de protections de sécurité

Des recherches récentes ont révélé une faille critique dans la compilation WebAssembly. Lorsqu’un programme C est compilé en WASM, il peut manquer de protections anti-exploit que les programmeurs tiennent pour acquises sur les architectures natives, car les protections de sécurité disponibles dans des compilateurs comme Clang pour les builds x86 ne sont pas présentes lors de la génération du WASM.

Des chercheurs ont compilé 4 469 programmes C avec des vulnérabilités de débordement de tampon connues en code x86 et WebAssembly, constatant que les résultats d’exécution différaient pour 1 088 programmes en raison de l’absence de mesures de sécurité telles que les canaris de pile dans le WebAssembly généré — alors que le code x86 plantait lors d’un débordement de tampon basé sur la pile, le WebAssembly correspondant poursuivait son exécution.

Cette découverte remet en question fondamentalement les hypothèses de sécurité que les développeurs ont sur WebAssembly. Sans protection contre le débordement de pile, les programmes WASM exploités peuvent continuer à fonctionner sous le contrôle d’un attaquant, alors que leurs homologues x86 s’arrêteraient pour leur propre sécurité.

Débordements de tampon dans WebAssembly : vieille menace, nouveau contexte

Comment les débordements de tampon se manifestent dans WASM

Alors que les débordements de tampon ne peuvent pas affecter les variables locales ou globales stockées dans l’espace d’index (qui sont de taille fixe et adressées par index), les données stockées dans la mémoire linéaire peuvent écraser des objets adjacents, puisque la vérification des limites est effectuée au niveau de la région mémoire linéaire et n’est pas sensible au contexte.

Dans certaines circonstances, des fonctions non sûres comme strcpy peuvent permettre à un attaquant d’écraser des variables locales lorsqu’elles sont stockées de manière contiguë en mémoire. Ce scénario classique de débordement de tampon se traduit directement dans l’environnement WebAssembly, permettant aux attaquants de corrompre la mémoire adjacente.

Attaques de corruption basées sur la pile

Les binaires WebAssembly continuent souvent leur exécution après un débordement de tampon et une corruption mémoire, en raison de l’absence de Stack Smashing Protection (SSP) dans les binaires WebAssembly, ce qui permet aux attaquants d’exploiter les débordements de tampon de manière plus furtive. Cela rend les binaires WebAssembly plus vulnérables à la corruption mémoire que leurs homologues natifs.

Les canaris de pile, qui servent de détecteurs d’attaques de débordement de tampon dans les applications natives, sont conspicuement absents de la plupart des binaires WASM. Cette décision architecturale a été prise en supposant que le sandboxing de WebAssembly offrirait une protection suffisante — une hypothèse que la recherche a montré problématique.

Corruption des métadonnées du tas

Des recherches ont démontré des techniques sophistiquées d’exploitation du tas dans WebAssembly. Dans des attaques de corruption des métadonnées du tas utilisant l’allocateur emmalloc, un débordement dans une allocation peut écrire directement dans les métadonnées adjacentes d’une autre allocation, manipulant le bit utilisé et créant une structure factice qui trompe l’allocateur lors des opérations de libération suivantes.

Ces attaques reflètent des techniques classiques d’exploitation du tas issues des plateformes natives, montrant que le sandboxing de WebAssembly ne supprime pas les risques fondamentaux de corruption mémoire — il les déplace simplement dans l’environnement du navigateur.

Vulnérabilités use-after-free dans les modules WebAssembly

Le danger persistant des pointeurs pendants

Les vulnérabilités use-after-free (UAF) surviennent lorsqu’un programme continue d’utiliser un emplacement mémoire après l’avoir libéré. Le code C non sécurisé reste dangereux lorsqu’il est compilé en Wasm, et les attaquants peuvent exploiter des débordements de tampon et des use-after-frees dans Wasm aussi facilement que sur des plateformes natives.

Des vulnérabilités récentes dans des outils WebAssembly incluent des problèmes de use-after-free, comme des découvertes CVE affectant la fonction GetFuncOffset de l’outil wabt. Ces vulnérabilités montrent que les pointeurs pendants persistent tout au long du processus de compilation du C/C++ vers WebAssembly.

Défis et opportunités d’exploitation

Bien que les vulnérabilités use-after-free existent dans WebAssembly, leur exploitation présente des défis et des opportunités uniques. L’absence de protections classiques contre la corruption mémoire signifie qu’une fois qu’un attaquant parvient à une condition UAF, la voie d’exploitation peut être plus simple qu’en environnement natif renforcé.

Cependant, le modèle d’exécution sandboxé de WebAssembly et ses mécanismes d’intégrité de contrôle limitent les techniques d’exploitation. Les attaquants ne peuvent pas injecter directement du code ni utiliser des gadgets ROP traditionnels comme en environnement natif.

Hijacking du contrôle de flux : la vulnérabilité des appels indirects

Exploiter les pointeurs de fonction

Le hijacking contrôlable du flux est possible en abusant de l’instruction call_indirect de WebAssembly, qui permet au langage de supporter des pointeurs de fonction nécessaires lorsque le compilateur ne peut pas déterminer statiquement la fonction exacte à appeler, comme pour des callbacks ou des méthodes dynamiques en programmation orientée objet. Ce mécanisme affaiblit l’intégrité du contrôle de flux implicitement enforceé par WebAssembly.

Lorsque des pointeurs de fonction sont compilés en variables stockées dans la mémoire linéaire, des attaquants ayant des capacités d’écriture arbitraire via des débordements de tampon peuvent modifier ces pointeurs pour rediriger l’exécution du programme. Bien que l’intégrité du contrôle de flux de WebAssembly garantisse que les cibles d’appel doivent être des fonctions valides déclarées au chargement, cela offre tout de même aux attaquants un sous-ensemble significatif de cibles potentielles pour le hijacking.

Amplification par Cross-Site Scripting (XSS)

Les débordements de tampon dans WebAssembly peuvent conduire à des vulnérabilités de type cross-site scripting lorsque des données corrompues sont utilisées ultérieurement dans la manipulation du DOM. Cela montre comment des bugs classiques de corruption mémoire peuvent avoir des conséquences spécifiques au web, faisant le pont entre exploitation de bas niveau et attaques d’applications web de haut niveau.

Les attaquants exploitant des corruptions mémoire dans les modules WASM peuvent utiliser ces vulnérabilités pour injecter des scripts malveillants, contourner les politiques de sécurité ou exfiltrer des données sensibles — tout cela en opérant dans la supposée sécurité du sandbox du navigateur.

Vulnérabilités et scénarios d’attaque dans le monde réel

Découvertes récentes CVE

L’écosystème WebAssembly a connu de nombreuses vulnérabilités documentées ces dernières années. En 2025, Google a corrigé la CVE-2025-5419 (score CVSS : 8.8), une vulnérabilité de lecture/écriture hors limites dans le moteur V8 JavaScript et WebAssembly permettant à des attaquants distants d’exploiter potentiellement une corruption du tas via des pages HTML manipulées.

En 2023, la vulnérabilité CosmWasm CVE-2023-33242 a permis à des contrats malveillants de provoquer des débordements de pile en exploitant des appels récursifs, avec des attaquants déployant des contrats qui invoquaient de manière répétée des fonctions à la frontière du contrat-runtime, provoquant des crashs de nœuds blockchain et interrompant les opérations.

Bombes WebAssembly et déni de service

La vulnérabilité CWA-2023-004, fin 2023 et début 2024, a permis à des attaquants de télécharger des contrats WebAssembly spécifiquement conçus pour apparaître inoffensifs en taille mais s’étendant massivement en mémoire lors du chargement, avec des contrats ne faisant que quelques centaines de kilo-octets mais s’étendant à des centaines de mégaoctets, provoquant des crashs de nœuds et menaçant la disponibilité de la chaîne.

Ces “bombes WebAssembly” illustrent comment la compilation et le comportement d’exécution de WebAssembly peuvent être exploités pour des attaques par déni de service, même sans briser directement le modèle de sécurité du sandbox.

Tentatives d’évasion du sandbox

CVE-2023-51661, une faille dans l’environnement d’exécution Wasmer, a permis à des contrats de contourner les restrictions de sécurité du sandbox, obtenant un accès non autorisé au système de fichiers du nœud. Cela représente l’une des catégories de vulnérabilités WebAssembly les plus graves — celles qui brisent les garanties fondamentales d’isolation qui rendent le WASM viable dans des environnements multi-locataires.

Le sandbox V8 : la réponse de Google aux menaces WASM

Un nouveau niveau de défense

En réponse aux préoccupations croissantes concernant la corruption mémoire dans WebAssembly, Google a annoncé le support du V8 Sandbox dans Chrome pour traiter ces problèmes, avec le sandbox conçu pour empêcher la propagation de la corruption mémoire dans V8 au sein du processus hôte. Ce sandbox léger, en cours d’exécution dans le même processus, cible spécifiquement les vulnérabilités courantes de V8 et WebAssembly.

Le V8 Sandbox représente un investissement architectural important pour contenir les dégâts liés aux vulnérabilités de corruption mémoire. Plutôt que d’essayer d’éliminer toutes les bugs de sécurité mémoire — une tâche probablement impossible étant donné la nature du code C/C++ — l’approche de Google se concentre sur la limitation de l’impact en cas d’exploitation.

Limitations et défis en cours

Bien que le V8 Sandbox offre une protection significative contre certaines classes d’attaques, il ne peut pas traiter toutes les préoccupations de sécurité WebAssembly. Une corruption mémoire dans un module WebAssembly peut toujours compromettre la logique de l’application, voler des données ou permettre des attaques de type cross-site scripting — sans sortir du sandbox.

De plus, le sandbox introduit une surcharge de performance et une complexité d’implémentation. Trouver un équilibre entre sécurité et la promesse de performance proche du natif de WebAssembly reste un défi permanent pour les fournisseurs de navigateurs et la communauté WebAssembly.

Défis de détection et d’analyse

Limitations de l’analyse statique

Les outils et techniques de sécurité traditionnels ne sont pas toujours efficaces pour détecter les vulnérabilités dans le code WebAssembly en raison de sa structure et de son modèle d’exécution uniques. La nature binaire de WASM, combinée à son architecture de machine virtuelle basée sur la pile, crée des angles morts pour les analyseurs de sécurité classiques.

Les outils d’analyse statique conçus pour le code natif ont souvent du mal avec la représentation différente de la mémoire, du contrôle de flux et des appels de fonctions dans WebAssembly. De même, les outils conçus pour JavaScript peuvent ne pas comprendre la sémantique bas niveau des modules WASM ou leur interaction avec l’environnement JavaScript.

La nécessité d’outils spécialisés

Une approche pour détecter les vulnérabilités dans le code WebAssembly consiste à utiliser des outils d’analyse statique capables d’analyser le code pour des problèmes de sécurité potentiels, avec la possibilité pour les développeurs d’implémenter des vérifications pour des erreurs courantes de corruption mémoire. Cependant, le développement d’outils de sécurité efficaces spécifiques à WASM reste un domaine de recherche actif.

Des travaux académiques récents se concentrent sur la création d’analyseurs spécialisés, de moteurs d’exécution symbolique et de frameworks de fuzzing adaptés aux caractéristiques uniques de WebAssembly. Ces outils représentent des avancées importantes pour une meilleure visibilité de sécurité dans les applications WASM.

Stratégies de mitigation et bonnes pratiques

Sécurité mémoire via le choix du langage

La mitigation la plus efficace contre les vulnérabilités de corruption mémoire consiste à utiliser des langages sûrs en mémoire. Les contrats WebAssembly peuvent bénéficier des constructions plus sûres de langages comme Rust, qui imposent la sécurité mémoire lors de la compilation. En compilant depuis Rust plutôt que C/C++, les développeurs peuvent exploiter le système de propriété et le vérificateur d’emprunt du langage pour prévenir toute une classe de bugs de sécurité mémoire.

D’autres langages sûrs en mémoire comme Go (avec des précautions concernant son implémentation en WASM), Swift, et le C++ moderne avec des standards de codage strict peuvent aussi réduire significativement la surface d’attaque.

Bonnes pratiques de codage sécurisé pour C/C++

Lorsqu’on travaille avec C/C++ et WebAssembly, il est conseillé d’utiliser la vérification des limites pour s’assurer que les modules n’accèdent qu’à la mémoire qui leur est allouée, d’éviter les fonctions non sûres pour prévenir les vulnérabilités de corruption mémoire, et d’implémenter des mécanismes de protection mémoire comme l’ASLR (Address Space Layout Randomization) et la prévention d’exécution de données (DEP).

Les développeurs doivent traiter les problèmes de sécurité du langage C aussi sérieusement en WASM qu’en environnement natif, éviter d’utiliser emscripten_run_script (car l’exécution dynamique de JavaScript depuis WASM est risquée), activer le flag Control Flow Integrity (-fsanitize=cfi) dans Clang, et optimiser pour supprimer certaines fonctions intégrées d’Emscripten pouvant être exploitées.

Validation et sanitation des entrées

Les développeurs doivent valider les données d’entrée, nettoyer les entrées utilisateur, et éviter les opérations mémoire non sûres pour réduire le risque de vulnérabilités. Ce principe de sécurité fondamental s’applique autant aux applications WebAssembly qu’à tout autre logiciel.

Une attention particulière doit être portée aux données traversant la frontière JavaScript-WASM. Les attaquants peuvent tenter d’exploiter des vulnérabilités de confusion de types ou de déclencher des débordements de tampon en fournissant des entrées malicieuses via l’API JavaScript.

Sandboxing et isolation

Mettre en place un mécanisme de sandboxing robuste qui limite les capacités des modules WebAssembly et empêche leur accès à des données sensibles ou des ressources système est crucial, avec des développeurs qui doivent faire respecter une isolation stricte entre le code WebAssembly et le reste de l’application pour réduire le risque d’évasion du sandbox.

Cette approche de défense en profondeur suppose que certaines vulnérabilités existeront et vise à limiter leur impact. En compartimentant les modules WebAssembly et en restreignant leur accès aux ressources système, les développeurs peuvent contenir d’éventuelles brèches.

L’avenir de la sécurité WebAssembly

Propositions de WebAssembly sûr en mémoire

WebAssembly Memory-Safe (MSWasm) propose d’étendre Wasm avec des abstractions de sécurité mémoire au niveau du langage pour traiter les problèmes de corruption mémoire, avec des programmes MSWasm bien typés conçus pour être robustement sûrs en mémoire par construction. Cela représente une solution potentielle à long terme aux défis fondamentaux de sécurité mémoire de WebAssembly.

La proposition MSWasm vise à préserver des informations sémantiques de haut niveau sur les opérations mémoire lors de la compilation, permettant aux systèmes d’exécution d’appliquer la sécurité mémoire sans nécessiter de modifications du code source. Cependant, l’adoption de telles extensions nécessite une coordination dans l’écosystème WebAssembly et pourrait entraîner des compromis de performance.

Améliorations du compilateur et de la chaîne d’outils

Près de 80 % de tous les binaires collectés sont compilés avec la chaîne d’outils LLVM, ce qui signifie qu’implémenter des mécanismes de sécurité comme la protection contre le débordement de pile dans LLVM permettrait d’ajouter une protection accrue à la majorité des programmes WebAssembly sans efforts supplémentaires. C’est une voie pratique pour améliorer la sécurité de WASM à grande échelle.

Les développeurs de compilateurs travaillent activement à intégrer des fonctionnalités de sécurité traditionnelles comme les canaris de pile, la protection du contrôle de flux et les sanitizers d’adresses dans les chaînes d’outils WebAssembly. À mesure que ces protections mûrissent, l’écart de sécurité entre les binaires natifs et WebAssembly devrait se réduire.

Défenses en runtime et surveillance

Les fournisseurs de navigateurs continuent d’innover dans les défenses en runtime contre l’exploitation de WebAssembly. Au-delà du V8 Sandbox de Google, d’autres approches incluent :

La compartimentation mémoire fine-grained
La mémoire assistée par matériel (memory tagging)
La surveillance en temps réel des comportements suspects de WASM
Le durcissement du compilateur JIT
Le renforcement de l’intégrité du contrôle de flux

Ces défenses multicouches reconnaissent qu’aucune mitigation unique ne peut éliminer tous les risques, nécessitant une approche de sécurité globale.

Tests de sécurité pour les applications WebAssembly

Fuzzing et exécution symbolique

Les techniques de test automatisé comme le fuzzing et l’exécution symbolique se sont révélées efficaces pour découvrir des vulnérabilités dans les modules WebAssembly. Ces approches peuvent explorer systématiquement les états du programme et les espaces d’entrée pour identifier des bugs de corruption mémoire avant que des attaquants ne le fassent.

Des outils spécialisés comme WAFL (WebAssembly Fuzzing with Fast Snapshots) et SeeWasm (exécution symbolique pour WebAssembly) offrent des capacités spécifiques à WASM qui améliorent la détection de vulnérabilités par rapport à des frameworks de test génériques.

Revue de code de sécurité

Étant donné que WebAssembly peut hériter de vulnérabilités issues du code source, une revue de sécurité approfondie du code C/C++ avant compilation est essentielle. Des recherches sur WebAssembly compilé à partir de C/C++ confirment que dans certains cas, le WebAssembly peut hériter de vulnérabilités cachées dans le code source qui deviennent exploitables.

La revue de code doit se concentrer sur : - Les modèles d’allocation et de désallocation mémoire - La gestion des buffers et la vérification des limites - L’arithmétique des pointeurs et leur déférencement - Le potentiel de débordement d’entiers - L’utilisation de fonctions C non sûres

Surveillance continue de la sécurité

Les organisations déployant des applications WebAssembly doivent mettre en place une surveillance continue pour détecter les tentatives d’exploitation. Cela inclut :

La détection d’anomalies dans le comportement des modules WASM
L’analyse des modèles d’accès mémoire
La surveillance des performances pour détecter des indicateurs de bombes WebAssembly
L’intégration avec des pare-feux applicatifs web
La réalisation régulière de scans de sécurité des modules WASM

Conclusion : Naviguer dans le paysage de la sécurité WebAssembly

WebAssembly représente une technologie transformatrice qui apporte des performances sans précédent aux applications web. Cependant, cette performance a un coût en sécurité — la réintroduction de vulnérabilités classiques de corruption mémoire qui ont longtemps hanté les applications natives.

Les défis de sécurité liés à WebAssembly ne sont ni insurmontables ni inattendus. Ils reflètent les compromis fondamentaux entre performance, compatibilité avec les bases de code existantes, et sécurité. À mesure que l’écosystème WebAssembly mûrit, nous constatons des progrès importants dans les outils de détection, les défenses en runtime, et les pratiques de développement sécurisé.

Pour les développeurs, la voie à suivre exige vigilance et une approche de sécurité en couches. Choisir des langages sûrs en mémoire lorsque possible, appliquer des pratiques de codage sécurisé en C/C++, exploiter les protections du compilateur disponibles, mettre en œuvre un sandboxing robuste, et effectuer des tests de sécurité approfondis contribuent à rendre les applications WebAssembly plus sûres.

Pour la communauté WebAssembly dans son ensemble, la recherche continue sur les extensions sûres en mémoire, l’amélioration des fonctionnalités de sécurité des chaînes d’outils, et le renforcement des défenses en runtime seront essentielles pour réaliser le plein potentiel de WASM sans compromettre la sécurité des utilisateurs.

L’ère des exploits natifs dans les navigateurs est là — mais tout comme les outils, la connaissance et l’engagement communautaire sont là pour y faire face efficacement. En comprenant ces risques et en mettant en œuvre des mesures de sécurité complètes, nous pouvons exploiter la puissance de WebAssembly tout en protégeant les utilisateurs contre les attaques de corruption mémoire.

Mots-clés : sécurité WebAssembly, vulnérabilités WASM, débordement de tampon, use-after-free, corruption mémoire, exploitation navigateur, exploits WebAssembly, sécurité code natif, corruption du tas, débordement de pile, hijacking de contrôle, sandbox V8, sécurité mémoire, mitigation WebAssembly, bonnes pratiques de codage sécurisé