isolated-vm : le bac à sable JS est percé

Ce qui se passe

Les chercheurs d'Endor Labs ont divulgué une faille critique dans isolated-vm, la bibliothèque Node.js de référence pour exécuter du JavaScript non fiable. Elle est référencée GHSA-864f-rcv7-6rh4 et n'a pas encore reçu d'identifiant CVE.

Toutes les versions jusqu'à la 7.0.0 incluse sont concernées. Les correctifs sont sortis plus tôt ce mois-ci, en 7.0.1 et 6.2.0.

L'ampleur tient au niveau d'adoption : le paquet npm approche du million de téléchargements hebdomadaires, et le dépôt compte environ 2 900 étoiles. La découverte est créditée à Cristian-Alexandru Staicu.

Comment ça marche

Chaque V8 Isolate possède son propre tas et son propre état. C'est précisément ce qui fait l'isolation — et ce qui interdit de passer directement un objet JavaScript du fil principal Node vers l'isolat invité.

isolated-vm résout ce problème avec une classe nommée ExternalCopy, chargée de sérialiser les objets côté hôte puis de les désérialiser côté invité. C'est ce pont, et non l'isolat, qui est cassé.

La faille est une confusion de type dans le traitement de l'option transferList. Elle permet au code enfermé dans l'isolat de corrompre la mémoire du processus hôte.

Le point de départ de l'exploitation mérite d'être souligné : une simple ivm.Reference. C'est la manière standard d'accorder la moindre capacité à un bac à sable — autrement dit, la configuration nominale de la bibliothèque, pas un montage exotique.

L'escalade documentée par les chercheurs va du plantage à adresse contrôlée jusqu'au détournement du flux de contrôle de l'hôte. Le mainteneur Marcel Laverdet décrit la fourchette dans son avis : impact minimal, un déni de service fiable par segmentation fault ; impact maximal, une exécution de code potentiellement distante dans le processus hôte.

Les chercheurs ont volontairement retenu les détails complets de l'exploit.

Ce que ça change

La leçon est plus large que la mise à jour à appliquer. Staicu la formule ainsi : « Ce qui n'a pas été cassé, c'est la primitive d'isolation elle-même. La frontière de l'Isolate V8 a tenu. Ce qui a échoué, c'est le code de liaison C++ qui fait passer les valeurs à travers cette frontière. »

Une brique parfaitement saine, minée par la couche d'adaptation enroulée autour. C'est un mode de défaillance à garder en tête chaque fois qu'on s'appuie sur une garantie de sécurité fournie par un binding natif : la garantie tient, la colle autour n'est pas couverte par la même revue.

Comment s'y prendre

Le risque suppose d'exécuter réellement du code non fiable. Si l'isolat ne sert qu'à cloisonner votre propre code, l'exposition reste théorique — mais la mise à jour ne coûte rien.

1. Passez en 7.0.1, ou en 6.2.0 si vous êtes resté sur la branche 6.
2. Cherchez le paquet dans vos dépendances transitives : isolated-vm est rarement installé directement, il arrive tiré par un moteur de workflow, un CMS ou une plateforme de règles métier. Un npm ls isolated-vm répond en une seconde.
3. Traitez les environnements de développement comme les serveurs : l'avis recommande explicitement la mise à jour des postes de développement.