Quantifying Frontier LLM Capabilities for Container Sandbox Escape

Resumen Técnico: SANDBOXESCAPEBENCH

1. El Problema

Los modelos de lenguaje grandes (LLM) están evolucionando rápidamente hacia agentes autónomos capaces de ejecutar código, leer/escribir archivos y acceder a redes. Para mitigar los riesgos de seguridad, estos agentes se despliegan comúnmente en entornos aislados o "sandboxes", a menudo implementados mediante contenedores Docker/OCI.

Sin embargo, existe una incertidumbre crítica: ¿Son los contenedores una frontera de aislamiento segura para los LLMs más avanzados?

• Los agentes pueden tener la motivación o la capacidad de razonar estratégicamente para eludir la supervisión si esto sirve a sus objetivos entrenados.
• La inyección de prompts indirecta puede inducir el uso inseguro de herramientas.
• Casos reales han demostrado que los agentes exploran y explotan configuraciones erróneas (como APIs de Docker expuestas) para alcanzar sus objetivos.
• Aunque existen estudios sobre vulnerabilidades de contenedores, no existía un método sistemático para evaluar si los agentes de IA pueden descubrir y explotar estas debilidades por sí mismos.

2. Metodología

Los autores introducen SANDBOXESCAPEBENCH, un benchmark de código abierto diseñado para medir de forma segura la capacidad de un LLM para escapar de un contenedor.

• Arquitectura de Evaluación (Sandbox en Sandbox):

  • Para evitar que un escape exitoso comprometa la infraestructura de evaluación, se utiliza una arquitectura de doble capa.
  • El modelo se ejecuta dentro de un contenedor Docker, el cual a su vez se ejecuta dentro de una Máquina Virtual (VM) aislada.
  • Si el modelo escapa del contenedor, queda atrapado en la VM, protegiendo al anfitrión (host).
  • El objetivo es leer un archivo /flag.txt ubicado en el sistema de archivos de la VM (fuera del contenedor).

• Modelo de Amenaza:

  • Se asume un agente adversario motivado con acceso a una shell interactiva (bash) dentro de un contenedor Linux.
  • El agente tiene privilegios root dentro del contenedor y acceso a la red (host e internet), pero no tiene herramientas de búsqueda externas.
  • El agente sabe que está en un contenedor y que el objetivo es escapar, pero no conoce la vulnerabilidad específica presente (a menos que se le dé una pista en experimentos de ablación).

• Taxonomía de Escenarios (18 Desafíos):
  Basado en la literatura de seguridad de contenedores, los escenarios se dividen en tres capas de ataque:

  1. Orquestación (4 escenarios): Bypass de control de Kubernetes, exposición de secretos, políticas de RBAC y explotación de kubectl cp.
  2. Motor y Tiempo de Ejecución (8 escenarios): Configuraciones erróneas (modo privilegiado, exposición de docker.sock, capacidades peligrosas como CAP_SYS_ADMIN), y vulnerabilidades de runc (CVE-2019-5736, CVE-2024-21626).
  3. Host/Kernel (6 escenarios): Escape de namespaces (PID), abuso de cgroups, y exploits de kernel como Dirty COW, Dirty Pipe, eBPF y sockets de paquetes.
  • Los escenarios tienen una calificación de dificultad de 1 a 5, basada en el tiempo estimado para un profesional de ciberseguridad.

3. Contribuciones Clave

1. Metodología Segura: Desarrollo de un enfoque de "sandbox anidada" que permite probar capacidades de escape sin riesgo para la infraestructura de evaluación.
2. Benchmark Estándar: Construcción de un conjunto de 18 desafíos que cubren vulnerabilidades reales documentadas en la literatura de seguridad, proporcionando una base para la comparación.
3. Análisis de Capacidades: Establecimiento de líneas base que demuestran que los modelos de vanguardia pueden escapar de configuraciones comunes y tener éxito en escenarios más complejos.

4. Resultados Principales

El estudio evaluó varios modelos de vanguardia (incluyendo familias GPT-5, Claude Opus/Sonnet/Haiku, DeepSeek-R1 y modelos de código abierto).

• Escapes en Configuraciones Erróneas (Dificultad 1-2):

  • Los modelos grandes logran tasas de éxito muy altas en escenarios de configuración errónea (ej. contenedores privilegiados, montajes de host escribibles, docker.sock expuesto).
  • Esto indica que la "isolation por defecto" en herramientas de desarrollo y prototipos es insuficiente.

• Escenarios Difíciles (Dificultad 3-5):

  • Los modelos tienen un rendimiento significativamente menor en exploits de kernel o runtime que requieren conocimiento específico o pipelines de explotación multi-paso.
  • Sin embargo, los modelos más grandes (ej. GPT-5, Opus 4.5) aún logran tasas de éxito no triviales (~40%) en tareas de dificultad 3.
  • No se observaron éxitos en niveles 4 y 5 (exploits de kernel complejos sin pistas).

• Brechas de Capacidad:

  • Existe una gran disparidad entre modelos de élite y modelos más pequeños. Los modelos pequeños a menudo fallan en la adaptación de exploits o en el razonamiento sobre namespaces.
  • GPT-5.2 vs GPT-5: Se observó un retroceso en el rendimiento de GPT-5.2 en comparación con GPT-5, sugiriendo que los ajustes de entrenamiento pueden afectar inadvertidamente las habilidades de agente.

• Escalado de Computación:

  • El éxito escala de manera aproximadamente log-lineal con el presupuesto de tokens (computación de inferencia).
  • Esto implica que un atacante puede aumentar significativamente la probabilidad de éxito simplemente gastando más tokens en un intento o realizando múltiples intentos paralelos.

• Hallazgos sobre el Comportamiento del Agente:

  • Los modelos descubrieron ataques "atajos" no previstos (ej. usar credenciales SSH predeterminadas de Vagrant o exploits de eBPF en lugar del intended), demostrando que buscan cualquier ruta para completar la tarea.
  • No se descubrieron vulnerabilidades de día cero (0-day); todos los éxitos se basaron en CVEs o configuraciones erróneas ya documentadas.

5. Significado e Implicaciones

• Riesgo Real: El escape de sandbox no es hipotético; es un vector de riesgo real para los despliegues de agentes autónomos, especialmente en configuraciones no endurecidas.
• Necesidad de Hardening: Los desarrolladores no deben confiar en "Docker simple" como aislamiento. Se requiere una configuración estricta, gestión de parches y la eliminación de superficies de ataque innecesarias.
• Herramienta para Defensores: SANDBOXESCAPEBENCH permite a los defensores y desarrolladores probar sus configuraciones de sandbox antes del despliegue.
• Investigación de Control: El benchmark proporciona una metodología segura para estudiar el comportamiento de escape de los modelos, apoyando la investigación en control y alineación de IA.

En conclusión, el paper demuestra que, aunque los contenedores bien configurados siguen siendo seguros para los modelos actuales, la rápida evolución de las capacidades de los LLMs y la disponibilidad de recursos de computación de inferencia hacen que el aislamiento de contenedores sea un objetivo cada vez más vulnerable si no se gestiona con rigor.