La vulnérabilité isolated-vm récemment identifiée met en lumière un risque critique pour les développeurs qui exécutent du JavaScript non fiable dans des environnements isolés. D’après les analyses publiées, un défaut de type confusion au niveau de la bibliothèque Node.js pourrait, dans certaines conditions, aboutir à une évasion du sandbox et à une exécution de code à distance sur le système hôte.
Le point d’attention principal concerne la manière dont les données sont copiées entre isolats V8. Même si isolated-vm est conçu pour exécuter plusieurs contextes JavaScript séparés sur une même machine, la faille viserait un mécanisme de transfert de mémoire, rendant possible un scénario d’abus menant à un crash ou à une prise de contrôle.
Comment isolated-vm isole l’exécution JavaScript
isolated-vm s’appuie sur les fonctionnalités d’Isolates de l’interface V8 de JavaScript. Concrètement, chaque Isolate correspond à une instance V8 distincte, avec son propre espace mémoire, son état d’exécution et son ramasse-miettes. L’objectif est de permettre l’exécution de plusieurs morceaux de code JavaScript dans des environnements cloisonnés, sans nécessiter de conteneur ni de machine virtuelle.
Dans la pratique, de nombreux projets utilisent isolated-vm pour faire tourner du code non fiable tout en maintenant une séparation stricte. Cette promesse repose sur l’idée que l’on peut limiter les capacités du code invité, même lorsqu’il s’exécute sur la même machine que le reste de l’application.
ExternalCopy et le transfert de mémoire entre Isolates
La vulnérabilité décrite affecte un élément précis : la fonction ExternalCopy, chargée de copier des données d’un Isolate à un autre. Le principe général est le suivant : la fonction sérialise des données dans un Isolate, puis les reconstruit dans le second contexte.
Pour des raisons de performance, isolated-vm utilise une structure appelée transferList. L’idée est d’indiquer à l’avance de grands ArrayBuffers afin de transférer la mémoire plus efficacement. Lors de l’opération, la mémoire serait détachée du côté source puis remise au destinataire.
La faille de type confusion exploitable via TOCTOU
Le problème provient de la logique de reconstruction : lors de la copie, le traitement de la liste des octets serait effectué en deux passages. L’analyse indique que le second passage fait confiance au résultat du premier, ce qui ouvre la porte à une faiblesse de type time-of-check/time-of-use (TOCTOU).
Pourquoi est-ce dangereux ? Parce que l’itération sur le tableau JavaScript ne renverrait pas forcément la même valeur à chaque passe si des getter sont impliqués. Un attaquant pourrait alors exploiter ce comportement pour influencer l’ordre des données et aboutir à un déréférencement d’un pointeur contrôlé par l’adversaire.
Le scénario d’attaque mentionne également un point clé : même si le constructeur d’ExternalCopy n’est accessible que depuis l’hôte, un code invité peut viser ivm.Reference, un mécanisme par lequel l’hôte expose des éléments au sandbox. En construisant une transferList malveillante, le code invité pourrait déclencher le comportement vulnérable.
Impact : crash, détournement du flux et RCE sur l’hôte
Lorsque l’exploitation réussit, les conséquences peuvent être sévères. L’un des résultats possibles est un crash, ce qui correspond à un déni de service. L’autre issue décrite est un détournement du flux de contrôle du processus hôte.
Dans ce dernier cas, la vulnérabilité peut potentiellement mener à une RCE (exécution de code à distance) sur l’hôte. Autrement dit, l’attaquant ne se contente plus de faire planter le sandbox : il pourrait franchir la frontière attendue entre le code non fiable et le système qui l’héberge.
Les recommandations sous-entendent que tout projet qui exécute du code non fiable dans un Isolate et qui partage au moins une Reference vers le sandbox est concerné. De plus, l’analyse précise que si le code hôte passe un tableau influençable par un appelant en tant que transferList, le risque est amplifié côté hôte, même sans action directe du sandbox sur ce paramètre.
Pourquoi la correction cible le “native glue code”
La correction a été intégrée dans des versions précises d’isolated-vm. Mais surtout, l’explication associée à la faille insiste sur la nature du problème. Le défaut se situerait dans le code natif de liaison (la couche C++), chargé de sérialiser et reconstruire les valeurs entre les frontières des isolats.
Cette couche opérerait avec des éléments V8 sensibles, comme des handles bruts et des pointeurs de backing-store. Le problème serait lié au fait que, pendant une opération de sécurité, des objets JavaScript contrôlés par un attaquant seraient relus au mauvais moment, transformant une primitive d’isolation correcte en mécanisme d’échappement.
Selon l’analyse, une erreur de casting non vérifiée lors de la relecture d’une valeur suffirait à renverser les garanties de séparation. En clair : même avec un design d’isolation soigné, la frontière natif/JS peut devenir le maillon faible si la logique de sécurité n’est pas parfaitement protégée.
Quelles versions corrigent la vulnérabilité isolated-vm
Les correctifs ont été intégrés dans isolated-vm 6.2.0 et isolated-vm 7.0.1. Si vous utilisez cette bibliothèque, la mesure la plus directe consiste à passer à ces versions (ou à des versions ultérieures).
Il est particulièrement important d’effectuer cette mise à jour lorsque votre application :
- exécute du JavaScript non fiable dans un Isolate ;
- utilise des mécanismes de copie, sérialisation ou transfert entre isolats ;
- partage des objets ou références côté hôte avec le sandbox ;
- permet qu’un paramètre externe influence la manière dont la transferList est formée.
Bonnes pratiques pour réduire le risque en attendant la mise à jour
Même si l’approche principale reste l’installation de correctifs, vous pouvez aussi limiter l’exposition en examinant votre intégration. Commencez par auditer les chemins d’exécution où des données passent d’un Isolate à un autre, en particulier ceux liés à ExternalCopy et au transfert de tampons.
Ensuite, vérifiez si votre code hôte fournit des structures dont le contenu pourrait être influencé par un tiers, directement ou indirectement. Comme la faille s’appuie sur un comportement différent selon des évaluations successives, la robustesse de votre validation d’entrée et la réduction des surfaces d’exposition deviennent des leviers importants.
Enfin, traitez toute utilisation de Reference côté sandbox comme un sujet sensible : plus vous exposez d’objets du monde hôte au code invité, plus vous augmentez la probabilité d’atteindre un chemin d’attaque. Cette logique vaut même si vous partez d’une architecture pensée pour isoler l’exécution.
En résumé : agir vite sur la vulnérabilité isolated-vm
La vulnérabilité isolated-vm met en évidence un risque critique : une faille de type confusion dans la copie entre isolats peut mener, sous certaines conditions, à un crash et potentiellement à une RCE sur l’hôte. Le mécanisme en cause s’articule autour de la fonction ExternalCopy et de l’exploitation d’une faiblesse TOCTOU liée à l’évaluation répétée d’éléments d’une liste de transfert.
Pour réduire le danger, mettez à jour votre bibliothèque vers isolated-vm 6.2.0 ou 7.0.1 dès que possible, puis auditez vos points de passage de données entre isolats et tout partage de Reference avec le sandbox. En combinant correctif et hygiène d’intégration, vous renforcez la séparation attendue et limitez la surface d’attaque.
Source: https://www.securityweek.com/critical-isolated-vm-vulnerability-leads-to-rce-on-host/
