Sandbox en Cohere AI Terrarium: funcionamiento, riesgos y vulnerabilidad crítica

Informatec Digital » Recursos » Sandbox en Cohere AI Terrarium: funcionamiento, riesgos y vulnerabilidad crítica

Cuando hablamos de ejecutar código Python no fiable o generado por una IA, uno de los grandes quebraderos de cabeza es cómo hacerlo de forma segura, rápida y sin arruinarse en infraestructura. En ese contexto apareció Terrarium, una solución de Cohere AI pensada como sandbox para alojar y ejecutar este tipo de código dentro de contenedores desplegados en la nube, especialmente en Google Cloud Run.

Este enfoque permitía que desarrolladores y empresas pudieran aprovechar Terrarium como un entorno aislado donde lanzar código de usuarios o de modelos LLM, con un coste bastante ajustado y un rendimiento razonablemente bueno. Sin embargo, con el tiempo también han salido a la luz vulnerabilidades muy serias, incluyendo una con identificador CVE que expone fallos críticos en la seguridad del sandbox y que ha puesto a Terrarium en el punto de mira.

Qué es Terrarium y para qué se diseñó

Terrarium es, en esencia, un entorno de ejecución aislado para Python, pensado para funcionar como un contenedor Docker desplegable, por ejemplo, en Google Cloud Run. Su objetivo principal es ofrecer un sandbox donde lanzar código potencialmente peligroso o desconocido (como scripts enviados por usuarios o fragmentos generados por modelos de lenguaje) sin poner en riesgo directo la infraestructura principal.

La filosofía detrás del proyecto se centra en disponer de un servicio económico, de baja latencia y fácil de integrar en flujos ya existentes. Terrarium se concibió para ser llamado mediante peticiones HTTP, enviando el código Python a ejecutar —y opcionalmente ficheros de entrada— y recibiendo de vuelta el resultado de la ejecución junto con los archivos generados.

En la práctica, esto se traduce en que un sistema externo, una API o incluso una herramienta interna puede delegar la ejecución de código Python en Terrarium, manteniendo ese código dentro de un entorno relativamente acotado, con reglas claras sobre recursos, tiempo de ejecución y capacidades permitidas.

Uno de los puntos clave del diseño es que Terrarium se apoya en Pyodide, una compilación de CPython a WebAssembly ejecutada dentro de un proceso de Node.js. Gracias a este enfoque, el código Python no se ejecuta de forma nativa en el sistema anfitrión, sino dentro de un intérprete encapsulado, lo que en teoría refuerza el aislamiento.

Rendimiento, costes y características principales del sandbox

Uno de los grandes argumentos a favor de Terrarium era su combinación de bajo coste operativo y rendimiento aceptable. En despliegues reales sobre Google Cloud Run, con una configuración típica de 2 GB de memoria, 1 vCPU y al menos una instancia siempre activa con autoescalado bajo demanda, el coste mensual reportado rondaba los 30 dólares durante fases internas de anotación.

En términos de velocidad, las pruebas descritas muestran que Terrarium podía generar, por ejemplo, una imagen PNG a 200 dpi de un gráfico sencillo de matplotlib en torno a los 900 ms de tiempo de ejecución, o una versión en SVG en aproximadamente 500 ms. Estos tiempos se refieren al código alojado en Cloud Run, incluyendo el ciclo de invocación típico del servicio.

Además del rendimiento, Terrarium presumía de estar totalmente compartimentado entre invocaciones. Tras cada llamada, el sandbox se reciclaba por completo: se descartaban el sistema de archivos virtual de Pyodide, las variables globales, las librerías cargadas y cualquier tipo de estado interno. El objetivo era que ninguna invocación heredara datos o contexto de una ejecución anterior, reduciendo así el riesgo de filtrado de información.

Otro punto importante es que, aunque se buscaba un aislamiento sólido, Cohere dejaba claro que no ofrecía garantías absolutas sobre la integridad del sandbox. Esto ya insinuaba que, pese a las capas de protección, existía la posibilidad de que se descubrieran debilidades, especialmente en un entorno tan complejo como el de WebAssembly y la integración con Node.js.

Terrarium estaba pensado para ser sencillo de consumir desde otros servicios: bastaba con realizar una petición HTTP al endpoint desplegado en Cloud Run, enviando el código a ejecutar y un token de autorización (si la configuración así lo requería). A cambio se obtenía un JSON con los resultados y, en su caso, los archivos generados codificados en base64.

Ejecución de archivos y soporte de librerías en Pyodide

Uno de los atractivos de Terrarium era su capacidad para trabajar con ficheros de entrada y salida de forma nativa. La API permitía adjuntar múltiples archivos de cualquier tipo junto con el código Python en la petición; estos se colocaban en el sistema de archivos virtual que Pyodide expone al intérprete de Python.

Durante la ejecución, el código Python podía leer y manipular esos archivos como si fueran locales dentro de la sandbox. Una vez finalizada la ejecución, Terrarium se encargaba de recopilar todos los ficheros creados o modificados y devolverlos en la respuesta al cliente, normalmente codificados para ser transferidos sobre HTTP sin problemas.

En cuanto al ecosistema de librerías, al basarse en Pyodide, Terrarium heredaba un conjunto bastante amplio de paquetes científicos y de análisis de datos. Entre los soportados de forma directa se incluyen: numpy, pandas, matplotlib, sympy, beautifulsoup4, python-sat, scikit-learn, scipy y sqlite3 (este último no habilitado por defecto, pero con la posibilidad de cargarlo si era necesario).

En el caso concreto de matplotlib, había algunas limitaciones: no se soportaba plt.show() en este entorno, pero sí funcionaba correctamente el uso de plt.savefig() para generar imágenes, siempre que no se forzaran parámetros excesivos, como resoluciones extremadamente altas que dispararan el uso de recursos.

Este conjunto de librerías hacía que Terrarium fuera especialmente útil para tareas de análisis de datos, visualización, prototipado de modelos de machine learning y manipulación de información estructurada, todo ello ejecutado dentro de un sandbox teóricamente controlado.

Arquitectura interna: capas de aislamiento y despliegue

La arquitectura de Terrarium está construida por varias capas pensadas para reducir la superficie de ataque y aislar al máximo el código no fiable. La primera capa es el propio proceso de Node.js, que actúa como anfitrión y en el que se carga Pyodide, es decir, CPython compilado a WebAssembly.

El código Python enviado por el usuario se parsea, compila y ejecuta dentro de ese entorno WebAssembly, no de forma nativa sobre el sistema anfitrión. Esta aproximación limita de entrada lo que el código puede hacer, puesto que Pyodide dispone de un sistema de archivos virtual en memoria, no tiene acceso directo al disco del host y carece de capacidades de procesos en segundo plano tradicionales.

Entre las restricciones más relevantes se incluyen: sin acceso al sistema de archivos real (solo al virtual interno de Pyodide), ausencia total de threading y multiprocessing, imposibilidad de lanzar subprocesos, sin acceso a la memoria del host que ejecuta Node.js, sin compartir estado entre llamadas (ya que se reinicia por completo el entorno) y, por diseño, sin acceso a la red ni a Internet. Esta última limitación se planteaba como una decisión de diseño que podría revisarse en el futuro, pero que inicialmente añadía una capa más de contención.

La segunda capa de aislamiento es el propio despliegue en la nube: el proceso de Node.js se ejecuta dentro de un contenedor Docker, que a su vez se despliega en Google Cloud Run. Esto no solo fija límites al tiempo de ejecución y a los recursos disponibles, sino que también desacopla el contenedor que ejecuta el código de cualquier otra parte de la infraestructura de la organización en caso de una hipotética fuga del sandbox.

En resumen, el diseño original de Terrarium confía en la combinación de WebAssembly, Docker y Cloud Run para construir un entorno relativamente blindado donde alojar la ejecución de Python, con barreras sucesivas que complican la huida del sandbox hacia el sistema anfitrión y la red interna.

Despliegue local, en Docker y en Google Cloud Run

Para utilizar Terrarium en un entorno de desarrollo, era necesario contar con Node.js instalado en la máquina. Una vez satisfecho ese requisito, el procedimiento habitual consistía en instalar las dependencias del proyecto y ejecutar el servidor local, junto con la función que hace de manejador de las peticiones de ejecución de código.

Con el servidor en marcha, se podían realizar peticiones al endpoint local para enviar archivos de prueba y scripts Python, de modo que el desarrollador pudiera validar el comportamiento de la sandbox antes de pasar a entornos de producción. Existían scripts pensados para lanzar un conjunto de pruebas sobre todos los ficheros .py de un directorio de test, simplificando así la verificación del entorno.

En escenarios de contenedores, Terrarium se podía construir como imagen Docker y ejecutar como un contenedor independiente. Las instrucciones típicas incluían los pasos de build, run y stop, además de comandos para localizar el identificador del contenedor en ejecución y gestionarlo de forma manual si era necesario.

Cuando se daba el salto a Google Cloud Run, Terrarium se desplegaba como un servicio HTTP autoscalable, con parámetros de recursos y concurrencia configurables. Era recomendable ajustar estos valores para equilibrar rendimiento, coste y seguridad. Por ejemplo, para cargas intensivas se podían asignar más CPU y memoria, así como limitar la concurrencia por instancia para evitar bloqueos.

Hay que tener en cuenta que Pyodide, en la configuración de Terrarium, se ejecuta en el proceso principal de Node.js. Esto implica que, si el código Python se vuelve especialmente pesado o entra en bucles complejos, puede bloquear la capacidad de Node.js para responder a otras peticiones. Pyodide sugiere el uso de Workers para escenarios donde sea necesario interrumpir ejecuciones o aislarlas aún más, pero ese enfoque complica la integración y, en algunos casos, limita el soporte de librerías como matplotlib.

Gestión de salud del servicio y problemas de estabilidad

En despliegues sobre Google Cloud Run, uno de los retos prácticos era controlar la salud del servicio y la recuperación ante bloqueos. Cloud Run, por defecto, no soporta directamente las comprobaciones de salud definidas en Dockerfile mediante HEALTHCHECK, de modo que se requería un pequeño ajuste adicional.

El procedimiento habitual consistía en describir el servicio de Cloud Run con gcloud, exportando la configuración a un archivo service.yaml. Dentro de ese YAML, se añadía una configuración de livenessProbe asociada a la imagen del contenedor para que Cloud Run pudiera detectar cuando el servicio dejaba de responder correctamente.

Una vez modificada la configuración, se reemplazaba el servicio existente con el comando adecuado de gcloud, de forma que Cloud Run pasaba a monitorizar activamente el estado del contenedor y a reiniciarlo si la comprobación de vida fallaba. Esta operación solo era necesaria la primera vez que se desplegaba un nuevo servicio con esa imagen concreta.

A nivel de Docker puro, existe una limitación adicional: el propio motor Docker no ofrece reinicios automáticos basados únicamente en HEALTHCHECK. Además, el proceso con PID 1 en el contenedor está especialmente protegido y no es tan sencillo de terminar desde dentro. Por ello, en algunos entornos se plantea el uso de herramientas de terceros como docker-autoheal, que monitorizan el estado del contenedor y fuerzan reinicios cuando detectan problemas.

En cuanto a la estabilidad de las ejecuciones, el equipo observó que, con cierta frecuencia, aparecían errores del tipo «RangeError: Maximum call stack size exceeded» dentro de Pyodide cuando se manejaban cargas especialmente pesadas. Esto era más habitual al usar valores de dpi muy elevados en la generación de PNG con matplotlib o al ejecutar operaciones de pandas especialmente complejas, algo que apunta a límites internos en el manejo de la pila dentro del entorno WebAssembly.

Vulnerabilidad crítica CVE-2026-5752 en Terrarium

Con el tiempo, se ha descubierto una vulnerabilidad de enorme gravedad en Terrarium, identificada como CVE-2026-5752 y valorada con una puntuación de 9,3 en el sistema de clasificación CVSS. Este nivel de criticidad indica que se trata de un fallo con un impacto potencial muy elevado sobre la seguridad de los sistemas que utilicen esta sandbox.

La debilidad permite a un atacante realizar ejecución de código arbitrario con privilegios de root en el proceso anfitrión. El vector de ataque se basa en un recorrido malicioso de la cadena de prototipos de JavaScript (prototype chain traversal) dentro del entorno de Pyodide en WebAssembly, lo que, en la práctica, abre la puerta a saltarse las restricciones impuestas por el sandbox.

Lo más preocupante es que para explotar esta vulnerabilidad no se requieren privilegios especiales ni interacción adicional del usuario. Un atacante que pueda inyectar código en la sandbox (por ejemplo, aprovechando una funcionalidad de ejecución de código en una herramienta que utilice Terrarium) puede aprovechar este fallo para escapar del entorno controlado.

Una vez explotada, la vulnerabilidad podría permitir acceso no autorizado a archivos sensibles del sistema, como /etc/passwd u otros recursos internos del contenedor, e incluso posibilitar la escalada hacia el host o a otros servicios que compartan la misma infraestructura, dependiendo de la configuración de seguridad general.

Esta situación supone un riesgo significativo para todas las organizaciones que utilicen Terrarium como entorno de ejecución de código de usuarios o de modelos de IA. No se trata solo de un fallo teórico, sino de un escenario en el que la ruptura del sandbox puede derivar en exposición de datos, compromiso de servicios internos y movimientos laterales dentro de la red.

Impacto para empresas, desarrolladores y usuarios finales

El hallazgo de esta vulnerabilidad afecta directamente a cualquier compañía o desarrollador que haya integrado Terrarium en su infraestructura para ejecutar código Python no confiable. Herramientas de desarrollo colaborativo, plataformas de aprendizaje, servicios de análisis bajo demanda o productos de asistencia de código basados en IA podrían estar expuestos si emplean Terrarium como capa de ejecución.

Desde el punto de vista del usuario final, el riesgo no es solo que el proveedor del servicio vea comprometida su infraestructura, sino que la información personal o profesional almacenada en esas plataformas pueda verse filtrada o manipulada sin previo aviso si un atacante logra explotar el fallo.

La gravedad aumenta porque se ha señalado que Terrarium ya no se mantiene activamente. Esto significa que no es previsible que llegue un parche oficial que corrija el problema, por lo que las organizaciones que sigan dependiendo de esta solución se encuentran ante una herramienta con una vulnerabilidad conocida y sin soporte.

En este contexto, seguir utilizando Terrarium sin medidas adicionales supone asumir un riesgo considerable en términos de seguridad. Los atacantes que conozcan el vector de explotación pueden dirigirse específicamente a servicios que continúen usando esta tecnología, buscando puntos débiles en la protección global del sistema.

Además, en entornos donde varios servicios comparten la misma red interna o incluso el mismo clúster de contenedores, una fuga desde Terrarium podría abrir la puerta a movimientos laterales hacia otros sistemas aparentemente aislados, lo que amplifica el impacto potencial de un ataque exitoso.

Estrategias de mitigación y alternativas a considerar

Ante una vulnerabilidad de este calibre y la ausencia de mantenimiento activo, la primera recomendación para las organizaciones es evaluar con urgencia el uso actual de Terrarium. Si se está utilizando para ejecutar código de terceros o generado por modelos de IA, la exposición es mayor y requiere acciones inmediatas.

Entre las medidas a corto plazo se incluye la posibilidad de deshabilitar temporalmente las funciones que permitan ejecutar código arbitrario en producción mientras se valora una alternativa más segura. También puede plantearse reforzar las políticas de red, segmentar aún más los servicios que utilizan Terrarium y limitar el acceso al contenedor desde otros sistemas.

A medio plazo, puede resultar más sensato migrar hacia otras soluciones de sandboxing o ejecución aislada que cuenten con mantenimiento activo y una comunidad o proveedor detrás que se encargue de parchear vulnerabilidades. Esto podría pasar por servicios gestionados, entornos de ejecución serverless con restricciones más fuertes o arquitecturas de microservicios diseñadas específicamente con seguridad por defecto.

En cualquier caso, este incidente pone de relieve la importancia de integrar buenas prácticas de seguridad en el ciclo de vida del desarrollo: auditorías periódicas de dependencias, revisión de componentes de terceros utilizados en la arquitectura, monitorización de CVE relevantes y planes de respuesta rápida cuando se detecta un fallo crítico.

Las empresas que construyen herramientas basadas en IA y que permiten al usuario final ejecutar o generar código deberían analizar de forma muy cuidadosa el diseño de sus sandboxes, asegurarse de que los procesos de aislamiento se mantienen actualizados y evitar depender de proyectos abandonados para funciones tan delicadas como la ejecución de código no confiable.

Todo lo relacionado con Terrarium refleja hasta qué punto ejecutar código de usuarios y de modelos LLM exige un enfoque de seguridad extremo. Un sandbox con buen rendimiento y coste bajo puede parecer muy atractivo, pero si aparece una vulnerabilidad crítica sin perspectiva de parche, el equilibrio se rompe y el riesgo pasa a ser inasumible para muchos casos de uso serios.