Plus forts ensemble : Snyk et le CISPA collaborent pour le bien commun

De grandes choses se produisent lorsque le monde universitaire et l’industrie du logiciel collaborent ! Aujourd’hui, nous souhaitons vous raconter notre récente collaboration avec le CISPA Helmholtz Center for Information Security, un important institut de recherche allemand.

En janvier, Cris Staicu Ph.D. (enseignant-chercheur titulaire d’un poste permanent au CISPA) nous a contactés au sujet de ses recherches sur NodeJS et JavaScript. L’étude menée par Staicu et son équipe portait sur des problèmes de sécurité intéressants dans les environnements JavaScript et NodeJS, notamment les vulnérabilités de pollution de prototype, les évasions de sandbox JS et les vulnérabilités de bas niveau en C/C++ dans les extensions natives de NodeJS.

Avec le CISPA, nous avons pu confirmer plusieurs vulnérabilités difficiles à détecter, les signaler aux responsables de maintenance afin qu’ils les corrigent, puis attribuer des CVE et publier des avis de sécurité.

Dans cet article, nous allons vous présenter quelques-unes des vulnérabilités découvertes avec le CISPA, tout en invitant d’autres établissements universitaires à collaborer avec nous pour rendre l’open source plus sûr pour tout le monde.

Techniques d’évasion de sandbox dans NodeJS

La première vulnérabilité sur laquelle nous avons travaillé était une vulnérabilité d’évasion de sandbox.

Si le terme « sandbox » ne vous est pas familier, il désigne un environnement, un processus ou une machine dans lesquels nous pouvons exécuter du code sans nous soucier des implications en matière de sécurité. C’est notamment utile lorsqu’il s’agit de code ou de fichiers fournis par un client et non assainis.

Dans ce cas, l’équipe de Cris a découvert une bibliothèque JS dont la sandbox pouvait être contournée. La bibliothèque concernée, notevil, ainsi que son dérivé argencoders-notevil, permettaient à l’équipe de Cris de contourner la sandbox en exploitant une vulnérabilité de pollution de prototype.

La preuve de concept de ce problème ressemble à ceci :

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

Bien que la preuve de concept ne semble pas dangereuse au premier abord, une vulnérabilité similaire dans la même bibliothèque avait déjà été signalée et peut entraîner une exécution de code à distance (RCE) dans les environnements NodeJS, ou une XSS dans les environnements de navigateur.

La bibliothèque étant déjà obsolète (mais toujours utilisée par beaucoup), l’équipe de Cris avait besoin de notre aide pour attribuer une CVE et avertir les responsables de maintenance. Pour information, Snyk est une CNA officielle, ce qui nous permet d’attribuer des CVE lorsque nécessaire. Nous avons donc attribué la CVE-2021-23771 afin d’informer les développeurs qui utiliseront cette bibliothèque à l’avenir.

Confusion de types dans les extensions natives de NodeJS

Comme les recherches du CISPA portaient sur les vulnérabilités de confusion de types entre les applications NodeJS et les extensions C du moteur NodeJS, nous avons collaboré sur ce sujet. La plupart des expériences du CISPA sur la confusion de types provoquaient le plantage du moteur V8 ; les deux équipes souhaitaient donc approfondir leurs recherches pour mieux comprendre le problème.

Prenons par exemple la bibliothèque libxmljs. Si vous ne la connaissez pas, libxmljs sert à analyser du XML et utilise en arrière-plan le binaire natif libxml.

Voici un extrait de l’exemple d’utilisation de base de la bibliothèque, tiré de son fichier 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

Nous avons toutefois réussi à faire planter toute l’application avec la preuve de concept suivante :

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}

Comme une entrée utilisateur permet de faire planter l’application, malgré la présence de blocs try/catch, nous avons affaire à un point d’entrée permettant un déni de service (DoS).

L’exécution du code du bloc précédent produit la trace de pile suivante :

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

Une analyse plus poussée avec GDB nous a permis de comprendre que le moteur sous-jacent attend un argument de type String, mais que, comme nous l’avons constaté, lorsqu’on lui transmet un objet, il tente de le convertir en chaîne.

Dans l’exemple ci-dessus, la méthode toString ne peut pas être appelée (car il s’agit simplement d’un nombre). V8 ne peut pas gérer cette situation et déclenche une exception. Cependant, comme cette exception est levée dans V8, les blocs try/catch ne sont pas efficaces, ce qui provoque le plantage complet de l’application.

Avec le CISPA, nous avons contacté les responsables de maintenance et leur avons signalé la vulnérabilité de manière responsable. Elle a été répertoriée sous le numéro CVE-2022-21144.

Appel à la collaboration

Nous aimerions collaborer avec d’autres établissements universitaires comme le CISPA. Un partenariat avec Snyk présente plusieurs avantages. Découvrir des vulnérabilités est une chose ; les divulguer en est une autre, surtout lorsqu’elles concernent des bibliothèques open source. Notre équipe dédiée d’analystes et de chercheurs vous aidera à vérifier une vulnérabilité et à en comprendre pleinement l’impact. Notre processus garantit une divulgation responsable, discrète et professionnelle. Enfin, comme Snyk est une CNA, nous disposons d’un système de suivi dédié et pouvons coordonner nos échanges avec le déclarant et les responsables de maintenance, afin que les deux parties restent informées à tout moment.

N’hésitez pas à nous contacter la prochaine fois que vous découvrirez une nouvelle vulnérabilité. Nous serons ravis de vous aider dans les démarches de confirmation et de divulgation.

Restez en sécurité !