Más seguros juntos: Snyk y CISPA colaboran por el bien común

¡Grandes cosas suceden cuando el mundo académico y la industria del software trabajan juntos! Hoy queremos compartir una historia sobre nuestra reciente colaboración con el CISPA Helmholtz Center for Information Security, una importante institución científica de Alemania.

En enero, Cris Staicu Ph.D. (profesor con titularidad en CISPA) se puso en contacto con nosotros para hablar sobre su investigación en NodeJS y JavaScript. El estudio que Staicu y su equipo realizaron se centró en interesantes problemas de seguridad en entornos JavaScript y NodeJS, como vulnerabilidades de contaminación de prototipos, escapes de sandbox de JS y vulnerabilidades de bajo nivel en C/C++ en extensiones nativas de NodeJS.

Junto con CISPA, pudimos confirmar algunas vulnerabilidades complejas, reportarlas a los responsables del mantenimiento para que las corrigieran, asignarles CVE y publicar avisos.

En esta publicación, te mostraremos algunas de las vulnerabilidades que encontramos con CISPA y también invitaremos a otras instituciones académicas a colaborar con nosotros para hacer que el mundo del código abierto sea más seguro para todos.

Gadgets para escapar del sandbox de NodeJS

La primera vulnerabilidad en la que trabajamos fue una vulnerabilidad de escape del sandbox.

Si no conoces el término “sandbox”, se refiere a un entorno, proceso o máquina donde podemos ejecutar elementos sin preocuparnos por las implicaciones de seguridad. Por ejemplo, cuando trabajamos con código o archivos proporcionados por el cliente sin sanitizar.

En este caso, el equipo de Cris encontró una biblioteca de JS con un sandbox que se podía evadir. La biblioteca reportada, notevil y su derivada argencoders-notevil, permitía al equipo de Cris evadir el sandbox mediante el abuso de una vulnerabilidad de contaminación de prototipos.

La PoC de este problema es así:

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

Aunque a primera vista la PoC no parece dañina, anteriormente se reportó una vulnerabilidad similar en la misma biblioteca, que puede provocar RCE en entornos NodeJS o XSS en entornos de navegador.

Como la biblioteca ya está obsoleta (pero muchas personas aún la usan), el equipo de Cris necesitaba nuestra ayuda para emitir un CVE y notificar a los responsables de su mantenimiento. Si no lo sabías, Snyk es una CNA oficial, lo que nos permite emitir CVE cuando es necesario. Así, emitimos CVE-2021-23771 para que quienes desarrollen en el futuro conozcan esta vulnerabilidad.

Confusión de tipos en extensiones nativas de NodeJS

Como CISPA se enfocaba en vulnerabilidades de confusión de tipos entre aplicaciones NodeJS y extensiones C para el motor NodeJS, colaboramos en este tema. La mayoría de los experimentos de CISPA sobre confusión de tipos provocaron fallas en el motor V8, por lo que ambas partes quisimos profundizar y entender mejor el problema.

Como ejemplo, usemos la biblioteca libxmljs. Si no la conoces, libxmljs se usa para analizar XML y utiliza el binario nativo libxml en segundo plano.

Aquí tienes un fragmento del ejemplo de uso básico de la biblioteca, copiado de su 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

Sin embargo, pudimos hacer que toda la aplicación fallara con la siguiente PoC:

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}

Como se puede hacer que la aplicación falle usando entradas del usuario, a pesar de los bloques try/catch implementados, tenemos un punto de entrada para un DoS.

Al ejecutar el código del bloque anterior, se obtiene el siguiente seguimiento de pila:

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

Una depuración más profunda con GDB nos ayudó a entender que el motor subyacente espera recibir un argumento de tipo String, pero, como descubrimos, cuando se le pasa un objeto, intenta convertirlo en una cadena.

En el ejemplo anterior, no se puede invocar el método toString (porque es solo un número). V8 no puede manejarlo y genera una excepción. Sin embargo, como esta excepción se produce en V8, los bloques try/catch no son eficaces, lo que provoca que toda la aplicación falle.

Junto con CISPA, nos pusimos en contacto con los responsables del mantenimiento y divulgamos la vulnerabilidad de forma responsable. La registramos como CVE-2022-21144.

Invitación a colaborar

Nos encantaría colaborar con más instituciones académicas como CISPA, y asociarse con Snyk ofrece varias ventajas. Descubrir vulnerabilidades es una cosa; divulgarlas es otra, sobre todo cuando afectan a bibliotecas de código abierto. Nuestro equipo especializado de analistas e investigadores te ayudará a verificar y comprender el impacto total de una vulnerabilidad. Además, nuestro proceso garantiza que se divulgue de forma responsable, discreta y profesional. Y como Snyk es una CNA, contamos con un sistema de seguimiento especial y podemos coordinar con quien reporta la vulnerabilidad y con sus responsables de mantenimiento, para mantener a ambas partes informadas en todo momento.

Así que no dudes en contactarnos la próxima vez que descubras una nueva vulnerabilidad. Con gusto te ayudaremos con los procesos de confirmación y divulgación.

¡Mantente seguro!