Vulnerabilidad crítica en isolated-vm permite escapar del sandbox

Investigadores de ciberseguridad han descubierto una vulnerabilidad crítica en isolated-vm, una biblioteca de código abierto para Node.js ampliamente utilizada para ejecutar código JavaScript no confiable dentro de entornos aislados. El fallo de seguridad puede permitir que un atacante que consiga ejecutar código dentro del sandbox corrompa la memoria del proceso anfitrión e incluso llegue a secuestrar su flujo de control, abriendo la puerta a una posible ejecución remota de código fuera del entorno aislado.

La vulnerabilidad, identificada como GHSA-864f-rcv7-6rh4, todavía no cuenta con un identificador CVE, pero su gravedad ha llevado a los responsables del proyecto a publicar actualizaciones de seguridad. El problema afecta a versiones de isolated-vm anteriores e incluyendo la 7.0.0, mientras que las versiones 6.2.0 y 7.0.1 incorporan las correcciones necesarias.

El descubrimiento fue realizado por el investigador Cristian-Alexandru Staicu, de Endor Labs, quien analizó el funcionamiento interno de la biblioteca y encontró un problema de confusión de tipos en uno de los componentes encargados de transferir datos entre el entorno anfitrión y el código ejecutado dentro del sandbox.

¿Qué es isolated-vm y por qué es importante?

isolated-vm es una biblioteca para Node.js diseñada para ejecutar código JavaScript potencialmente no confiable dentro de un V8 Isolate, una instancia independiente del motor JavaScript V8 utilizado por Google Chrome y Node.js.

El objetivo de este mecanismo es crear una separación entre el código considerado confiable y aquel que puede representar un riesgo. De esta manera, diferentes entornos JavaScript pueden ejecutarse simultáneamente manteniendo estados y memoria separados.

Su popularidad convierte cualquier vulnerabilidad de aislamiento en un asunto especialmente relevante para desarrolladores y organizaciones que utilizan esta tecnología para ejecutar código de terceros, funciones dinámicas, scripts o cargas de trabajo que no deberían tener acceso directo al proceso principal.

El paquete disponible en npm ha registrado cerca de un millón de descargas durante la última semana, mientras que el proyecto de código abierto acumula más de 2.900 estrellas y alrededor de 190 forks en GitHub. Estas cifras reflejan el nivel de adopción de isolated-vm dentro del ecosistema JavaScript.

El problema está en ExternalCopy

La vulnerabilidad no afecta directamente al mecanismo fundamental de aislamiento de V8. El problema se encuentra en la capa de integración que permite intercambiar determinados valores entre el proceso anfitrión y el entorno aislado.

Debido a que cada V8 Isolate mantiene su propio estado y heap, los objetos JavaScript no pueden transferirse directamente entre el hilo principal de Node.js y un isolate. Para resolver esta limitación, isolated-vm utiliza una clase denominada ExternalCopy, encargada de serializar objetos de manera que puedan trasladarse de forma controlada entre ambos entornos.

Precisamente en esta funcionalidad se encuentra el fallo de seguridad.

Según la investigación de Endor Labs, una confusión de tipos relacionada con la gestión de la opción transferList puede ser aprovechada por código ejecutado dentro del sandbox para provocar una corrupción de memoria en el proceso anfitrión.

Esto es especialmente preocupante porque el modelo de seguridad de isolated-vm parte de una premisa fundamental: aunque el código ejecutado dentro del sandbox sea malicioso, debe permanecer confinado y no tener capacidad para manipular directamente el proceso que lo aloja.

De un bloqueo del proceso a un posible escape del sandbox

La explotación de la vulnerabilidad puede producir diferentes niveles de impacto.

El escenario mínimo demostrado consiste en provocar una corrupción de memoria controlada que puede terminar con el cierre inesperado del proceso anfitrión mediante un fallo de segmentación, conocido como SIGSEGV. En términos prácticos, un atacante podría utilizar un sandbox comprometido para provocar una condición de denegación de servicio contra la aplicación que ejecuta isolated-vm.

Sin embargo, el problema es considerablemente más grave que un simple bloqueo.

La investigación demostró que la corrupción de memoria puede escalar hasta permitir el secuestro del flujo de control del proceso anfitrión. Si un atacante logra controlar suficientemente este comportamiento, el aislamiento entre el código invitado y la aplicación anfitriona puede quedar comprometido.

El impacto potencial máximo es, por tanto, una posible ejecución remota de código en el proceso anfitrión.

Esto significa que una aplicación que utilice isolated-vm como barrera de seguridad para ejecutar código no confiable podría quedar expuesta si permite que un atacante ejecute código dentro del entorno aislado y posteriormente explote esta vulnerabilidad.

La capa C++ fue el punto débil

Uno de los aspectos más importantes del descubrimiento es que el problema no representa una ruptura del aislamiento fundamental proporcionado por V8.

El investigador Cristian-Alexandru Staicu explicó que el límite de aislamiento del motor V8 continúa funcionando como estaba previsto. El problema surgió en el código de enlace escrito en C++, encargado de gestionar los valores que atraviesan la frontera entre ambos entornos.

Esta distinción es importante desde el punto de vista de la seguridad. Un mecanismo de sandbox puede contar con una arquitectura de aislamiento sólida y, aun así, quedar comprometido por errores en las capas que conectan ese mecanismo con el resto de la aplicación.

En este caso, el componente vulnerable actuó como un puente entre el entorno confiable y el código aislado. Una validación o gestión incorrecta de los tipos permitió que una operación que debería haber permanecido confinada terminara afectando la memoria del proceso anfitrión.

¿Quiénes están en riesgo?

La vulnerabilidad resulta especialmente relevante para aplicaciones que utilizan isolated-vm para ejecutar JavaScript no confiable o código proporcionado por terceros.

Entre los escenarios potencialmente afectados se encuentran plataformas que ofrecen ejecución de scripts, servicios que procesan código enviado por usuarios, sistemas de automatización, herramientas de desarrollo, plataformas serverless y aplicaciones Node.js que emplean sandboxes como mecanismo de seguridad.

El riesgo aumenta cuando el código ejecutado dentro del isolate procede de fuentes externas o no confiables. En estos escenarios, el sandbox representa precisamente la barrera destinada a impedir que ese código interactúe con el proceso anfitrión.

Por ello, una vulnerabilidad de escape puede transformar un compromiso limitado del entorno aislado en una amenaza mucho más amplia para el servidor o aplicación subyacente.

Versiones afectadas y actualización recomendada

Los responsables del proyecto recomiendan actualizar isolated-vm a una versión corregida lo antes posible.

La vulnerabilidad afecta a las versiones anteriores e incluyendo la 7.0.0, mientras que las correcciones fueron incorporadas en las versiones 6.2.0 y 7.0.1.

Los administradores y desarrolladores deberían comprobar qué versión de isolated-vm utilizan sus proyectos y revisar especialmente aquellas aplicaciones que ejecutan código JavaScript no confiable.

La actualización debe formar parte de una estrategia más amplia de seguridad de la cadena de suministro de software. Además de actualizar la dependencia, conviene revisar qué código puede ejecutarse dentro de los sandboxes y si existen mecanismos adicionales de aislamiento, control de privilegios y monitorización.

Una advertencia para los desarrolladores de Node.js

El caso de isolated-vm demuestra que un sandbox no debe considerarse automáticamente una frontera de seguridad infalible. Incluso cuando el motor subyacente proporciona mecanismos sólidos de aislamiento, las capas de integración pueden introducir vulnerabilidades capaces de comprometer todo el modelo de confianza.

Para los desarrolladores, la principal lección es mantener actualizadas las dependencias que desempeñan funciones de seguridad, especialmente aquellas que interactúan directamente con componentes nativos escritos en C o C++.

También resulta recomendable minimizar las capacidades otorgadas a los entornos aislados y evitar proporcionarles más privilegios o referencias de las estrictamente necesarias.

En fin...

La vulnerabilidad GHSA-864f-rcv7-6rh4 en isolated-vm debe considerarse un problema de alta prioridad para cualquier organización que utilice esta biblioteca como mecanismo de sandboxing para ejecutar código no confiable.

Aunque los detalles técnicos completos del exploit no se han divulgado públicamente para reducir el riesgo de ataques oportunistas, la investigación ya demuestra que el fallo puede pasar de una denegación de servicio por corrupción de memoria a un posible escape del sandbox y ejecución de código en el proceso anfitrión.

La medida más importante es actualizar isolated-vm a una versión corregida, preferiblemente 7.0.1 o posterior, y verificar que ninguna aplicación crítica continúe utilizando versiones vulnerables.

El incidente también pone de manifiesto una realidad fundamental en ciberseguridad: el aislamiento no depende únicamente del componente que crea la frontera de seguridad. Una vulnerabilidad en el código que conecta un entorno aislado con el proceso anfitrión puede ser suficiente para erosionar toda esa protección. En el caso de isolated-vm, el problema estuvo precisamente en esa capa de enlace, demostrando que incluso un primitivo de aislamiento sólido puede verse comprometido por una implementación vulnerable a su alrededor.

Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login