Digital Eliteboard - Das Digitale Technik Forum

Registriere dich noch heute kostenloses um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereiche, welche für Gäste verwehrt bleiben

Hardware & Software Schwachstelle in JavaScript-Sandbox vm2 erlaubt Ausbruch aus der Isolation

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)
Du musst dich Anmelden oder Registrieren um diesen link zusehen!
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
Du musst dich Anmelden oder Registrieren um diesen link zusehen!
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
Du musst dich Anmelden oder Registrieren um diesen link zusehen!
(virtuellen Maschine).

Fehler-Tracing als Fehlerquelle​

Die Schwachstelle findet sich im Tracing, das eigentlich dazu dienen soll, Fehler nachzuvollziehen. Die
Du musst dich Anmelden oder Registrieren um diesen link zusehen!
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:
Ein Zugriff auf die Methode getThis() vom CallSite-Objekt ermöglicht den Ausbruch aus der Sandbox
(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.

Du musst dich Anmelden oder Registrieren um diesen link zusehen!



Das Diagramm zeigt den Angriffsvorgang vom Überschreiben des Error-Objekts bis zum Ausbruch aus der Sandbox.
(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
Du musst dich Anmelden oder Registrieren um diesen link zusehen!
. Die Schwachstelle ist
Du musst dich Anmelden oder Registrieren um diesen link zusehen!
.
Du musst dich Anmelden oder Registrieren um diesen link zusehen!

Quelle: heise
 
Zurück
Oben