Eine isolated-vm Schwachstelle wurde als kritisch eingestuft: Eine Typverwechslung (Type Confusion) in der Node.js-Bibliothek kann Angreifern ermöglichen, den Zugriff von einer isolierten JavaScript-Umgebung auf den Host auszuweiten. Im Erfolgsfall sind je nach Ausnutzung ein Absturz oder sogar eine Übernahme des Host-Prozesses möglich.
isolated-vm ist dafür bekannt, vollständig getrennte JavaScript-Umgebungen auf Basis der V8-Engine bereitzustellen. Gerade weil diese Sandboxes häufig genutzt werden, um untrusted Code auszuführen, ist die Tragweite der Sicherheitslücke besonders relevant für Integratoren.
Was macht isolated-vm so besonders?
isolated-vm bietet Entwicklern eine Möglichkeit, über die Isolate-Schnittstelle der V8-Engine vollständig isolierte JavaScript-Laufzeiten zu erstellen. Jede Isolate besitzt einen eigenen Speicherbereich (Heap), einen eigenen Ausführungszustand und einen eigenen Garbage Collector. Dadurch können mehrere gesandboxte Code-Instanzen parallel auf derselben Maschine laufen, ohne dass zwingend Container oder virtuelle Maschinen erforderlich sind.
In der Praxis wird isolated-vm oft eingesetzt, um untrusted JavaScript innerhalb einer V8-Isolation auszuführen. Die Idee: Der Code soll sich innerhalb der Isolate bewegen, ohne den Host oder andere Umgebungen direkt beeinflussen zu können.
Die Schwachstelle: Typverwechslung in ExternalCopy
Der neu identifizierte Fehler betrifft die Funktion ExternalCopy. Diese wird genutzt, um Daten zwischen zwei Isolates zu übertragen. Dabei wird die Ausgangsdatenstruktur in einer Isolate serialisiert und im Zielkontext wieder aufgebaut.
Für Performanceoptimierungen setzt ExternalCopy auf eine transferList. Diese Liste enthält große ArrayBuffers. Die zugrunde liegenden Speicherbereiche werden dabei nicht einfach kopiert, sondern übertragen: Der Quellpuffer wird dabei von seiner Seite abgetrennt (detached) und anschließend an das Ziel übergeben.
Wie Angreifer die Sicherheitsprüfung umgehen können
Das Kernproblem entsteht, wenn während des Kopiervorgangs auf die transferList vertraut wird. Beim Wiederaufbau iteriert der Reconstruktor die Byte-Array-Liste zweimal. Die zweite Iteration verlässt sich dabei auf das, was beim ersten Durchlauf als Referenz oder Wert angenommen wurde.
Genau hier greift eine TOCTOU-Schwäche (Time-of-check/Time-of-use). In JavaScript kann ein Element der transferList als Getter definiert sein. Dadurch kann der Rückgabewert je nach Zeitpunkt der Auswertung variieren. Resultat: Die zweite Iteration arbeitet mit einem Pointer, der letztlich vom Angreifer kontrollierbar wird.
Im Zusammenspiel mit nativen Speicheroperationen kann das dazu führen, dass ein korrekt wirkender Isolationsmechanismus nicht mehr sicher bleibt.
Warum auch der Host betroffen sein kann
Interessant ist dabei die Angriffsoberfläche: Der ExternalCopy-Konstruktor ist zwar nur vom Host-Code aus zugänglich. Allerdings kann ein Gast (also die Isolate) über ein Mechanismus namens ivm.Reference indirekt Einfluss auf die Konstruktion von Datenstrukturen nehmen, die der Host für die Kopie verwendet.
Damit reicht unter Umständen schon ein einzelnes Reference-Objekt, das der Host in die Sandbox übergibt. Laut den Hinweisen zur Sicherheitslage ist dann jeder Embedder betroffen, der untrusted Code in einer Isolate ausführt und mindestens eine solche Referenz teilt.
Außerdem können Host-Szenarien direkt betroffen sein, wenn Host-Code eine Liste weitergibt, deren Inhalt vom Aufrufer beeinflusst werden kann—insbesondere, wenn diese Liste als transferList in den Copy-Prozess gelangt.
Konsequenzen: DoS bis hin zur Kontrolle
Wenn Angreifer die Schwachstelle ausnutzen, ist nicht nur ein harmloser Fehler denkbar. Die erfolgreiche Ausnutzung kann zu einem Crash führen, was einem Denial-of-Service entspricht. Je nach Ausgestaltung der Attacke kann es jedoch auch zu einer Kontrollfluss-Umleitung innerhalb des Host-Prozesses kommen.
In diesem Fall besteht die Möglichkeit, dass Angreifer die Sicherheit der Host-Umgebung durchbrechen und Remote Code Execution (RCE) auf dem Host erreichen.
Was die Herstelleranpassungen leisten: Patches für betroffene Versionen
Für die isolated-vm Schwachstelle wurden bereits Korrekturen bereitgestellt. Diese sind in den Versionen 6.2.0 und 7.0.1 enthalten.
Die Änderungen zielen darauf ab, zu verhindern, dass JavaScript-Code überhaupt in einem sensiblen Schritt während des Kopiervorgangs ausgeführt wird. Damit wird die Möglichkeit reduziert, über Getter oder andere zeitabhängige Mechanismen ungewollten Einfluss auf die nativen Operationen zu nehmen.
Warum nativer Code hier die entscheidende Rolle spielt
Ein weiterer wichtiger Punkt ist, wo der Fehler technisch verankert ist. Laut den technischen Hinweisen lebt die Sicherheitslücke im sogenannten nativen „Glue“-Code—also der C++-Bindung, die Werte zwischen den Grenzen serialisiert und rekonstruiert.
Diese Ebene arbeitet mit nativen Speicherstrukturen, rohen V8-Handles und Zeigern auf Backing Stores. In solchen Umgebungen kann bereits ein kleiner Fehler in der Handhabung von Objekttypen oder ein unerwartetes erneutes Auslesen eines Werts ausreichen, um aus einem isolierten Prinzip eine vollständige Umgehung zu machen.
Konkret wurde beschrieben, dass ein ungeprüfter Cast auf einem neu ausgelesenen Wert ausreichte, um eine scheinbar korrekte Isolationslogik in eine potenzielle Escape zu verwandeln.
Checkliste: So gehen Integratoren jetzt vor
Wenn Sie isolated-vm einsetzen, lohnt sich jetzt ein kurzer Sicherheits-Check. Beginnen Sie mit der Aktualisierung auf eine gefixte Version. Prüfen Sie anschließend, wie Ihre Anwendung References an die Sandbox übergibt und ob transferList aus potenziell angreiferbeeinflussten Daten aufgebaut wird.
- Upgrade durchführen: Nutzen Sie isolated-vm 6.2.0 oder 7.0.1 (oder eine spätere, gesicherte Version).
- Data-Flow prüfen: Suchen Sie nach Stellen, an denen transferList oder vergleichbare Listen aus Nutzereingaben entstehen.
- Reference-Sharing reduzieren: Übergeben Sie möglichst wenige Objekte in die Isolate und vermeiden Sie, dass Untrusted-Code relevante Handles beeinflussen kann.
- DoS-Risiko mitdenken: Auch ohne vollständige Escape sollte ein Absturz als Sicherheitsereignis bewertet werden.
Fazit
Die isolated-vm Schwachstelle zeigt eindrucksvoll, dass selbst gut etablierte Sandbox-Konzepte durch Fehler in nativen Komponenten kompromittiert werden können. Die Typverwechslung in ExternalCopy kombiniert sich mit einer TOCTOU-Schwäche rund um transferList-Iterationen und kann im Worst Case zum Escape aus der Isolation bis hin zu RCE auf dem Host führen.
Wer isolated-vm für die Ausführung von untrusted JavaScript nutzt, sollte die betroffenen Versionen dringend aktualisieren und besonders die Datenflüsse rund um ExternalCopy und ivm.Reference sorgfältig überprüfen.
Quelle: https://www.securityweek.com/critical-isolated-vm-vulnerability-leads-to-rce-on-host/
