Isolated-vm Vulnérabilité permet la corruption de mémoire et l'évasion de bac à sable

Les chercheurs en sécurité ont révélé une vulnérabilité critique dans la bibliothèque open source isolée-vm - une liaison Node.js pour exécuter un JavaScript peu fiable dans des instances de moteurs V8 isolées - qui permet le code contenu dans le bac à sable pour corrompre la mémoire du processus hôte et même, dans des scénarios prouvés, échapper à la boîte d'isolement elle-même. La décision, publiée sous l'identificateur GitHub Security Advisory GHSA-864f-rcv7-6rh4, affecte toutes les versions jusqu'au 7.0.0 inclus et a été corrigé dans les versions récemment publiées 6.2.0 et 7.0.1. La découverte est attribuée à Cristian-Alexandru Staicu de Endor Labs et la correction se trouve dans le dépôt du projet à GitHub.

En termes techniques confirmés, isolé-vm crée plusieurs Isolats V8 - des instances séparées du moteur V8 avec des tas et des états indépendants - de sorte que les applications Node.js peuvent fonctionner code peu fiable sans partager des objets JavaScript directement entre le processus principal et l'isolé. Pour déplacer les données entre ces limites, une couche de « colle » est utilisée en C + + qui sérialise et désérialise les valeurs; dans cette couche, la bibliothèque expose la classe Extérieur, conçu pour copier en toute sécurité des objets de l'hôte à l'invité et vice versa. Endor Labs indique que l'échec est confusion de type dans la gestion de l'option de transfert ExternalCopy, qui permet à un client de manipuler des structures internes et de causer la corruption de la mémoire dans le processus hôte.

Les effets techniques des chercheurs comprennent, dans le cas minimum, une défaillance contrôlée qui provoque un SIGSEGV (défaut de service du processus hôte) et, dans le pire des cas, la prise de contrôle du flux d'exécution de l'hôte, qui ouvre la voie à l'exécution de code à distance dans le processus qui abrite le bac à sable. Le responsable du projet, Marcel Laverdet, a confirmé que l'impact minimum est un accident reproductible par tout invité recevant un ivm. Référence - la façon standard de donner la capacité au bac à sable - et que l'impact maximum démontré était une séquestration du contrôle du débit de l'hôte.

Il est important de séparer ce qui est confirmé de ce qui est encore incertain. Confirmé : la vulnérabilité existe, a été signalée publiquement et analysée dans des versions spécifiques; le vecteur implique ExternalCopy and transferList; le potentiel de corruption de la mémoire et de fuite de bac à sable a été démontré par les chercheurs et décrit par les chefs de projet. Incertitude: il n'y a aucune preuve d'exploitation massive dans les environnements de production, aucun identifiant public CVE attribué à l'échec, et les détails complets de l'exploitation ont été conservés par les découvertes pour éviter de faciliter les attaques.

La portée pratique du problème dépend de l'utilisation de l'isolat-vm dans chaque projet. La librairie est populaire dans l'écosystème Node.js - son paquet npm enregistré environ un million de téléchargements dans la dernière semaine selon les mesures publiques - et est utilisé à la fois dans les services qui permettent l'exécution à distance des scripts utilisateurs, ainsi que dans les environnements de test et les outils de développement. Ceux qui exécutent des instances isolées-vm qui acceptent un code non fiable ou de subvention ivm. La référence aux clients est plus risquée parce que la capacité minimale nécessaire pour exploiter l'échec est précisément d'avoir cette référence à l'intérieur de l'isolement.

Les conséquences réelles peuvent aller de l'indisponibilité localisée (processus d'écrasement) à des engagements de serveur ou de service plus sérieux hébergeant le bac à sable si une ferme parvient à exécuter le code sur l'hôte. En outre, la violation de la limite de confiance hôte-hôte sape l'objectif principal de l'utilisation d'isolats : exécuter un code potentiellement dangereux sans compromettre le reste de l'environnement.

Recommandations pratiques et vérifiables pour les gestionnaires et les développeurs concernés: mise à jour les corrections sont disponibles dans le dépôt officiel et en npm. Vous pouvez vérifier et installer la version parachevée avec des commandes commenpm ls isolé-vm --allpour localiser les unités, suivie denpm installer isolé-vm @ 7.0.1(ou la version minimale de sécurité requise par votre chaîne d'approvisionnement)npm reconstructionsi votre environnement a besoin de remodeler des modules natifs. Voir la page officielle du projet dans GitHub pour la note de sécurité : GitHub Security Advisory et l'entrée npm: isolé-vm dans npm.

Si vous ne pouvez pas mettre à jour immédiatement, appliquer l'atténuation du temps: éviter de livrer ivm. Référence a Code source non fiable; minimiser les privilèges du processus qui exécute le bac à sable; encapsuler chaque bac à sable dans des processus distincts avec des limites de ressources et des politiques du système d'exploitation (p. ex. utilisateurs non privilégiés, cgroups, seccomp, namespaces) pour réduire l'impact d'un crash ou d'une exécution arbitraire; et surveiller les signes d'exploitation (crashs répétés du processus, comportements anormaux, en dehors du commun). De plus, les unités de transition de vérification avec des outils tels que Dependabot, Snyk ou npm audit pour identifier les bibliothèques qui traînent isolé-vm.

Du point de vue de la conception de logiciels, cet incident rappelle que la sécurité d'un bac à sable dépend non seulement de l'isolement de V8 - les Isolats ont gardé la frontière selon les chercheurs - mais aussi de la mise en œuvre correcte du code natif qui en fait un pont entre les limites de mémoire. Comme le souligne Endor Labs, une "solide primitive" (la limite d'isolat V8) peut être compromise par des erreurs dans la couche de liaison C + +.

Enfin, des mesures à court terme recommandées pour les équipes de sécurité : hiérarchiser le dispositif dans les déploiements exposés, revoir la politique d'octroi de la capacité des bacs à sable (éviter les références lorsque ce n'est pas strictement nécessaire), mettre en place des alertes d'abandon des processus et procéder à un examen médico-légal des incidents si des signes d'exploitation sont détectés. À moyen terme, il convient de réévaluer le modèle d'exécution de code peu fiable - par exemple, de déplacer les charges vers des processus entièrement isolés au niveau du système ou d'utiliser des technologies de séparation des privilèges plus robustes - et de maintenir un canal de mise à jour automatisé pour les dépendances critiques. Pour comprendre comment les isolats fonctionnent au niveau du moteur et pourquoi la couche marsfining est si sensible, vous pouvez voir la documentation V8: Isolats V8 - v8.dev.

En bref, il y a un échec prouvé dans l'isolement-vm qui permet la corruption de mémoire des boîtes de sable et a été corrigé; l'action immédiate est de mettre à jour et de revoir l'octroi de la capacité aux invités, tandis que l'incertitude sur l'utilisation dans les attaques réelles nécessite un suivi et un audit continus.