Un problema de seguridad recién identificado pone en foco una vulnerabilidad de aislador en isolated-vm, una librería de Node.js que permite ejecutar código JavaScript en entornos aislados dentro del motor V8. Según las investigaciones publicadas, el fallo puede aprovechar una debilidad de tipo y copiar datos entre instancias de V8 para terminar afectando al proceso anfitrión.
El punto clave es que aislado-vm se usa para ejecutar JavaScript que no se confía plenamente. En ese escenario, una falla en la lógica de copia de datos deja de ser solo un error “dentro del sandbox”: puede conducir a una denegación de servicio o, en el peor caso, a la toma de control del flujo del proceso del host, abriendo la puerta a RCE.
Qué hace isolated-vm y por qué se usa
isolated-vm se apoya en la interfaz de Isolate del motor V8. Cada Isolate representa una instancia completamente separada de V8, con su propio montón (heap), estado de ejecución y recolector de basura. Gracias a esta separación, es posible ejecutar múltiples instancias de JavaScript en la misma máquina, sin necesidad de crear contenedores o máquinas virtuales.
En la práctica, esto permite a los desarrolladores correr código “no confiable” dentro de un entorno controlado, minimizando el impacto de fallos en la lógica del código ejecutado. justamentamente por ese objetivo, isolated-vm se ha vuelto relevante para escenarios donde hay que aislar ejecución.
El fallo: confusión de tipos durante ExternalCopy
La investigación indica que el bug, de severidad crítica, corresponde a un tipo de confusión de tipos asociado a la función ExternalCopy. Esta función se utiliza para copiar datos entre Isolates: un Isolate serializa la información y otro la reconstruye.
Cuando el sistema necesita mejorar rendimiento, la copia puede realizarse con un mecanismo adicional basado en una transferList, donde se listan ArrayBuffers grandes. En ese flujo, la memoria subyacente se transfiere mediante un proceso donde el buffer se “desprende” del origen y se entrega al destino.
El problema aparece porque, durante la reconstrucción, el proceso recorre la lista de bytes dos veces. En la segunda iteración, se confía en el contenido del primer recorrido, lo cual abre una ventana para explotar condiciones de tipo TOCTOU (time-of-check/time-of-use).
TOCTOU y getters: cómo se rompe la suposición
El punto delicado se relaciona con cómo se evalúa la transferList cuando sus elementos se definen con getters. El análisis señala que iterar el arreglo de JavaScript puede no devolver el mismo valor para un elemento en cada pasada si hay getters activos. Así, un atacante podría aprovechar la discrepancia entre lo “verificado” en la primera iteración y lo “usado” en la segunda para terminar con una referencia a un puntero controlado por el atacante.
En otras palabras: el sistema asume que la información observada en la primera vuelta será equivalente a la segunda, pero la semántica de JavaScript permite que eso no sea cierto.
Impacto potencial: desde denegación de servicio hasta RCE
Cuando un atacante logra explotar el defecto, los resultados pueden incluir desde un crash del sistema —lo que equivale a una denegación de servicio— hasta un escenario más serio donde se produce un control-flow hijacking del proceso del host.
La consecuencia final de este último caso es la posibilidad de RCE en el anfitrión. Es decir, un aislamiento que pretendía mantener la ejecución bajo control puede fallar precisamente en el “puente” que permite copiar o compartir datos entre Isolates.
Quién se ve afectado: anfitriones que comparten referencias
La recomendación y el alcance del riesgo dependen de cómo se integre isolated-vm en una aplicación. El aviso mencionado en la investigación destaca un principio: cualquier solución que ejecute código no confiable en un Isolate y además comparta al menos una referencia hacia ese entorno puede verse afectada.
En particular, se menciona que el código del host que pasa una matriz influenciable por el llamador como transferList está expuesto de manera directa. También se apunta que el impacto no depende únicamente de que el “guest” tenga un control total del entorno: incluso sin que el invitado controle todo, ciertas entradas del lado del host pueden ser suficientes para activar el problema.
Por qué el parche es crucial
En este caso, la mitigación no se reduce a ajustar parámetros del lado de la aplicación sin más: la corrección se incorporó en versiones específicas de isolated-vm. Según el reporte, las actualizaciones incluyen los arreglos en las versiones 6.2.0 y 7.0.1.
El objetivo del cambio es evitar que el código JavaScript del usuario pueda ejecutarse durante la operación de copia, que es precisamente donde se materializa la condición problemática. Esto es relevante porque el fallo nace en el cruce entre datos serializados y reconstrucción en otro Isolate, especialmente cuando se involucran estructuras como transferList.
La causa subyacente: “glue” nativo y manejo inseguro de memoria
El análisis también subraya que la vulnerabilidad no residía únicamente en la lógica de alto nivel, sino en el código nativo de enlace (la capa C++ que serializa valores entre límites). Este componente trabaja con mecanismos de V8 que implican handles y punteros a zonas de respaldo de datos.
La explicación indica que durante una operación sensible de seguridad, esa capa vuelve a leer objetos del JavaScript que potencialmente controla un atacante. Además, se menciona que una conversión sin validación (un cast no verificado) al re-leer un valor fue suficiente para transformar un mecanismo de aislamiento correcto en una salida completa del sandbox.
Recomendaciones prácticas para equipos de desarrollo
Si tu proyecto utiliza isolated-vm para ejecutar JavaScript no confiable, conviene revisar el riesgo con rapidez. Aunque el detalle técnico del fallo es complejo, la acción preventiva suele ser directa.
- Actualiza isolated-vm a las versiones con parche: 6.2.0 o 7.0.1, según tu compatibilidad.
- Revisa el uso de ExternalCopy y especialmente las rutas donde se emplea transferList y ArrayBuffers.
- Identifica inputs influenciables: si tu aplicación construye transferList con datos que provienen del llamador, aplica controles y valida entradas.
- Evalúa el uso de referencias (Reference) compartidas entre el host y el Isolate: el aviso indica que compartir al menos una referencia puede ser determinante.
Incluso después de actualizar, es recomendable confirmar que tu flujo de copia y reconstrucción de datos entre Isolates funciona como esperas y que no aparecen errores inesperados relacionados con transferencias de memoria.
Qué significa para la seguridad de sandboxes basados en V8
Este caso sirve como recordatorio de que los sandboxes no se rompen solo por fallos en el “código invitado”. A menudo, la ruptura ocurre en el canal de comunicación entre el entorno aislado y el anfitrión: en este escenario, la operación de copia y reconstrucción de datos en V8.
Cuando existe una vulnerabilidad de aislador en esa frontera, las garantías de separación pueden fallar. Por eso, para quienes integran soluciones basadas en V8, la estrategia de seguridad debe incluir tanto el aislamiento del código como la revisión del código nativo y los mecanismos de intercambio de datos.
Conclusión
La investigación publicada sobre isolated-vm revela una vulnerabilidad de aislador crítica vinculada a una confusión de tipos y a la copia de datos mediante ExternalCopy. El fallo puede provocar desde denegación de servicio hasta hijacking del flujo del proceso, con posibilidad de RCE en el host.
La respuesta recomendada es clara: actualiza a las versiones 6.2.0 o 7.0.1 y revisa cómo tu aplicación construye transferList, comparte referencias y ejecuta código no confiable en Isolates.
Fuente: https://www.securityweek.com/critical-isolated-vm-vulnerability-leads-to-rce-on-host/
