Schwachstelle in JavaScript-Sandbox vm2 erlaubt Ausbruch aus der Isolation
Wer eine Version kleiner 3.9.11 von vm2 verwendet, sollte die Sandbox aktualisieren, da eine Schwachstelle das Ausführen von Remote-Code auf dem Host erlaubt.
(Bild: Sashkin/Shutterstock.com)
- Rainald Menge-Sonnentag
Sicherheitsforscher des auf Cloud-native-Security ausgerichteten Unternehmens Oxeye haben eine Schwachstelle in der JavaScript-Sandbox vm2 gefunden. Versionen vor 3.9.11 erlauben Remote Code Execution und nutzen dafür die Error-API der JavaScript-Engine V8. Das Oxeye-Team hat den Fehler bereits im August gefunden und den vm2-Entwicklern mitgeteilt, mit der Veröffentlichung aber bis Oktober gewartet.
GitHub hat dem CVE-Eintrag (Common Vulnerability and Exposures) CVE-2022-36067 die Severity-Stufe "Critical" mit dem höchsten CVSS-Wert (Common Vulnerability Scoring System) 10 gegeben. Die aktuelle Version von vm2 schließt die Sicherheitslücke, aber für ältere Version gibt es keine bekannte Schutzmaßnahme. Wer vm2 verwendet, sollte umgehend ein Update durchführen. Die Sandbox ist durchaus verbreitet und kommt laut der Projektseite beim Paketmanager npm wöchentlich auf gut 3,4 Millionen Downloads.
vm2 ist eine Anwendung, die potenziell unsicheren JavaScript-Code in einer isolierten Umgebung abspielt. Das Sandboxing soll eigentlich dafür sorgen, dass der fremde Code keinen Zugriff auf das System hat. vm2 setzt auf Node.js und ist eine Alternative zu dessen integrierter VM (virtuellen Maschine).
Fehler-Tracing als Fehlerquelle
Die Schwachstelle findet sich im Tracing, das eigentlich dazu dienen soll, Fehler nachzuvollziehen. Die JavaScript-Engine V8 bietet die API Error.prepareStackTrace. Node.js nutzt die Methode und gibt ihr CallSite-Objekte als Parameter mit. Diese Objekte stehen für Stack-Frames, die zusammen den Aufruf-Stack beim Auftreten des Fehlers repräsentieren.
Den eigentlichen Weg aus der Sandbox bietet die Methode getThis in CallSite. Sie kann für this Objekte zurückgeben, die außerhalb der Sandbox erstellt wurden. Damit ist eine direkte Ausführung von Code auf dem Host-System möglich:
(Bild: Oxeye)
Gefahr erkannt, aber nicht ganz gebannt
Der Angriff ersetzt somit zunächst das Error-Objekt mit einer eigenen Implementierung. Daraufhin löst er einen Fehler aus, der das Error-Tracing anstößt, das schließlich zum Aufruf der Implementierung und dem Ausbruch aus der Sandbox führt.
(Bild: Oxeye)
Offenbar war der vm2-Community die Gefahr bewusst, dass ein Überschreiben der Funktion prepareStackTrace einen Ausbruch aus der Sandbox ermöglicht. Als Sicherheitsmaßnahme bietet vm2 eigene Wrapper für die Funktion und das Error-Objekt. Die Sicherheitsforscher mussten daher den Umweg über den JavaScript-Typ WeakMap gehen, um die Methode auszutauschen.
Weitere Details zur Vorgehensweise lassen sich dem Blogbeitrag mit der Metallica-Referenz im Titel entnehmen. Die Schwachstelle ist im aktuellen Release von vm2 behoben.
(rme)
