© gioiak2 / 123RF.com

Programmierfehler hebeln den Sandbox-Mechanismus einer Javascript-Umgebung aus. Angreifer haben dadurch freie Bahn.

Sandboxes dienen im Allgemeinen dazu, Programmcode in einer sicheren Umgebung auszuführen. Javascript wird beispielsweise im Webbrowser in einer eigenen Sandbox ausgeführt. Dadurch erhalten die Javascript-Programme nur Zugriff auf die Objekte des Browsers, nicht aber auf das Dateisystem oder andere Teile des Hosts. Neben der internen »vm.SandBox« von Javascript gibt es die alternative Vm2-Implementierung.

Die Vm2-Sandbox setzt dabei ihrerseits auf Node.js auf. Diese plattformübergreifende Laufzeitumgebung kann Javascript-Code auch außerhalb eines Webbrowsers laufen lassen. Die Vm2-Sandbox startet wie das Javascript-Original potenziell unsicheren Javascript-Code in einer isolierten und sicheren Umgebung. Sie ist recht weitverbreitet und kommt auf den verschiedensten Systemen und in zahlreichen Szenarien zum Einsatz. Laut NPM Package Manager wird sie monatlich mehr als 16 Millionen Mal heruntergeladen. Aufgrund der vielseitigen Anwendungen der Vm2 sind Sicherheitslücken darin besonders kritisch.

Ein Team von Sicherheitsforschern von Oxeye hat Anfang Oktober genau solch eine kritische Schwachstelle im Vm2-Sandbox-Schutzmechanismus veröffentlicht [1]. Über dieses Sicherheitsleck können Angreifer aus der Vm2-Sandbox ausbrechen und Befehle ausführen, beispielsweise direkt Shell-Kommandos auf dem Host-Rechner initiieren. Der CVSS-Wert (Common Vulnerability Scoring System) von 10,0 kennzeichnet diese Sicherheitslücke als sehr kritisch.

Der Angreifer bricht über den Error-Tracking-Mechanismus des Javascript-Systems aus der Vm2-Sandbox aus. Node.js gibt Entwicklern die Möglichkeit, den Call Stack eines in der Applikation auftretenden Fehlers zu verändern. Dazu muss der Programmierer die Methode »prepareStacktrace« des globalen Error-Objekts anpassen. Tritt dann ein Fehler in der Applikation auf, ruft Node.js diese Methode auf. Dabei übergibt es neben einem String zur Fehlerbeschreibung auch ein Array von CallSite-Objekten als Argument. Jedes der CallSite-Objekte in dem Array stellt einen anderen Stack Frame dar. Zusammengenommen bilden sie den Call Stack zum Zeitpunkt, als der Fehler auftrat.

Mithilfe dieser Informationen kann der Entwickler die eigentliche Ursache des Fehlers durch Zurückverfolgen herausfinden. Zu den Methoden der CallSite-Objekte zählt die »getThis()«-Methode. Sie liefert das This-Objekt des entsprechend Stack Frames zurück. Genau hier setzt der Angriff an. Einige der CallSite-Objekte können nämlich beim Aufruf von »getThis()« Objekte zurückgeben, die außerhalb der Sandbox erzeugt wurden. Dadurch gelangt der Angreifer auch an globale Objekte und kann damit aus der Sandbox ausbrechen und Befehle ausführen.

Das Muster der Attacke klingt recht einfach. Den Vm2-Entwicklern war dieser Umstand auch bekannt, weshalb sie die Methode »prepareStackTrace« durch ihre eigene Implementierung ersetzt haben, die eigentlich solche Attacken unterbinden sollte. Insbesondere wollten sie damit verhindern, dass Anwender die Methode überschreiben. Allerdings wurde dieser Schutzmechanismus nicht konsequent umgesetzt. Konkret haben die Vm2-Entwickler vergessen, einige Methoden des Javascript-Typs »WeakMap« abzusichern. Aufgrund dessen können die Angreifer die Methode »prepareStackTrace« dennoch überschreiben, einen Fehler auslösen und damit dann aus der Sandbox ausbrechen.

Trotz Absicherung ist die Attacke damit immer noch möglich. Betroffen sind alle Vm2-Sandbox-Versionen vor 3.9.11. (jcb/jlu)