Gemeinsam sicherer: Snyk und CISPA setzen sich für das Gemeinwohl ein

Wenn Wissenschaft und Softwarebranche zusammenarbeiten, entstehen großartige Dinge! Heute möchten wir Ihnen von unserer kürzlichen Zusammenarbeit mit dem CISPA Helmholtz Center for Information Security, einer bedeutenden Forschungseinrichtung in Deutschland, erzählen.

Im Januar wandte sich Cris Staicu Ph.D. (Tenure-Track-Faculty-Mitglied am CISPA) an uns, um über seine Forschung zu NodeJS und JavaScript zu sprechen. Die Studie, die Staicu und sein Team durchführten, befasste sich mit interessanten Sicherheitsproblemen in JavaScript- und NodeJS-Umgebungen, etwa Prototype-Pollution-Schwachstellen, dem Ausbrechen aus JS-Sandboxen und Low-Level-Schwachstellen in C/C++ in nativen NodeJS-Erweiterungen.

Gemeinsam mit CISPA konnten wir einige nicht ganz offensichtliche Schwachstellen bestätigen, sie den Maintainer:innen zur Behebung melden, CVEs zuweisen und Advisories veröffentlichen.

In diesem Beitrag stellen wir Ihnen einige der Schwachstellen vor, die wir gemeinsam mit CISPA entdeckt haben. Außerdem möchten wir andere akademische Einrichtungen dazu aufrufen, mit uns zusammenzuarbeiten, damit die Open-Source-Welt für alle sicherer wird.

NodeJS-Sandbox-Escape-Gadgets

Die erste Schwachstelle, an der wir gearbeitet haben, ermöglichte das Ausbrechen aus einer Sandbox.

Falls Ihnen der Begriff „Sandbox“ nicht geläufig ist: Damit ist eine Umgebung, ein Prozess oder ein Computer gemeint, in dem bzw. auf dem wir Dinge ausführen können, ohne uns Gedanken über Sicherheitsauswirkungen machen zu müssen. Ein Beispiel ist der Umgang mit nicht bereinigtem, vom Client bereitgestelltem Code oder Dateien.

In diesem Fall entdeckte Cris’ Team eine JS-Bibliothek mit einer umgehbaren Sandbox. Die gemeldete Bibliothek notevil und ihre Ableitung argencoders-notevil ermöglichten es Cris’ Team, die Sandbox mithilfe einer Prototype-Pollution-Schwachstelle zu umgehen.

Der PoC für dieses Problem sieht so aus:

1var notevil = require('notevil')
2
3notevil(`  
4Object.defineProperty(({})[["__proto__"]][["__proto__"]], 'polluted', {
5  value: 'success'
6});`);
7
8console.log(polluted); // prints "success"

Auch wenn der PoC auf den ersten Blick harmlos wirkt, wurde eine ähnliche Schwachstelle in derselben Bibliothek bereits zuvor gemeldet. Sie kann in NodeJS-Umgebungen zu RCE und in Browser-Umgebungen zu XSS führen.

Da die Bibliothek bereits veraltet ist (aber noch von vielen verwendet wird), benötigte Cris’ Team unsere Hilfe bei der Vergabe einer CVE und der Benachrichtigung der Maintainer. Falls Sie es noch nicht wussten: Snyk ist eine offizielle CNA und kann bei Bedarf CVEs vergeben. Deshalb haben wir CVE-2021-23771 vergeben, damit Entwickler:innen künftig auf diese Schwachstelle aufmerksam werden.

Typverwechslung in nativen NodeJS-Erweiterungen

Da CISPA sich auf Typverwechslungen zwischen NodeJS-Anwendungen und C-Erweiterungen für die NodeJS-Engine konzentrierte, arbeiteten wir zu diesem Thema zusammen. Die meisten Typverwechslungsexperimente von CISPA führten zu einem Absturz der V8-Engine. Daher wollten beide Seiten genauer untersuchen und verstehen, worin das Problem bestand.

Als Beispiel betrachten wir die Bibliothek libxmljs. Falls Sie sie nicht kennen: libxmljs wird zum Parsen von XML verwendet und nutzt im Hintergrund die native Binärdatei libxml.

Hier sehen Sie einen Ausschnitt aus dem grundlegenden Anwendungsbeispiel der Bibliothek, kopiert aus deren README:

1// As copied from libxmljs readme
2var libxmljs = require("libxmljs");
3var xml =  '<?xml version="1.0" encoding="UTF-8"?>' +
4           '<root>' +
5               '<child foo="bar">' +
6                   '<grandchild baz="fizbuzz">grandchild content</grandchild>' +
7               '</child>' +
8               '<sibling>with content!</sibling>' +
9           '</root>';
10
11var xmlDoc = libxmljs.parseXml(xml); // you can now query the document

Wir konnten jedoch die gesamte Anwendung mit dem folgenden PoC zum Absturz bringen:

1let libxmljs = require("libxmljs");
2let xml = {toString: 23};
3try { 
4    libxmljs.parseXml(xml);
5} catch(e) {
6    // never executed because of the hard crash
7}

Da sich die Anwendung trotz vorhandener try/catch-Blöcke durch Benutzereingaben zum Absturz bringen lässt, haben wir es mit einem DoS-Einstiegspunkt zu tun.

Beim Ausführen des Codes aus dem vorherigen Abschnitt wird der folgende Stacktrace ausgegeben:

1FATAL ERROR: v8::ToLocalChecked Empty MaybeLocal.
2 1: 0xb23a90 node::Abort() [node]
3 2: 0xa3823c node::FatalError(char const*, char const*) [node]
4 3: 0xd13ffa v8::Utils::ReportApiFailure(char const*, char const*) [node]
5 4: 0x7fa0bc5eec9b libxmljs::XmlDocument::FromXml(Nan::FunctionCallbackInfo<v8::Value> const&) [/opt/node_modules/libxmljs/build/Release/xmljs.node]
6 5: 0x7fa0bc5ea208  [/opt/node_modules/libxmljs/build/Release/xmljs.node]
7 6: 0xd7019e  [node]
8 7: 0xd715bf v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) [node]
9 8: 0x16138f9  [node]
10Aborted

Weitere Untersuchungen mit GDB halfen uns zu verstehen, dass die zugrunde liegende Engine ein Argument vom Typ String erwartet. Wie wir jedoch feststellten, versucht sie, ein Objekt in einen String umzuwandeln, wenn ein solches übergeben wird.

Im obigen Beispiel kann die Methode toString nicht aufgerufen werden, da es sich lediglich um eine Zahl handelt. V8 kann damit nicht umgehen und löst eine Ausnahme aus. Da diese Ausnahme jedoch in V8 auftritt, greifen die try/catch-Blöcke nicht – die gesamte Anwendung stürzt ab.

Gemeinsam mit CISPA wandten wir uns an die Maintainer und meldeten die Schwachstelle verantwortungsvoll. Sie wird unter CVE-2022-21144 geführt.

Aufruf zur Zusammenarbeit

Wir würden uns freuen, mit weiteren akademischen Einrichtungen wie CISPA zusammenzuarbeiten. Eine Partnerschaft mit Snyk bietet dabei mehrere hilfreiche Vorteile. Schwachstellen zu entdecken ist das eine – sie offenzulegen, insbesondere wenn sie Open-Source-Bibliotheken betreffen, das andere. Unser spezialisiertes Team aus Analyst:innen und Forschenden unterstützt Sie dabei, die Auswirkungen einer Schwachstelle zu überprüfen und vollständig zu verstehen. Unser Prozess stellt sicher, dass die Schwachstelle verantwortungsvoll, vertraulich und professionell offengelegt wird. Und da Snyk eine CNA ist, verfügen wir über ein spezielles Tracking-System und können den Austausch zwischen meldender Person und Maintainer koordinieren, sodass beide Seiten stets informiert sind.

Melden Sie sich also gerne bei uns, wenn Sie das nächste Mal eine neue Schwachstelle entdecken. Wir unterstützen Sie gerne bei der Bestätigung und Offenlegung.

Bleiben Sie sicher!