Escape de microVM Firecracker mediante manipulación de registros KVM

Investigadores de seguridad han demostrado una vulnerabilidad crítica en Firecracker, la tecnología de virtualización de código abierto utilizada para impulsar plataformas de computación sin servidor (serverless). Mediante la manipulación de los registros de CPU guardados durante una transición específica del kernel, lograron ejecutar código como root en la máquina anfitriona. El exploit, detallado en noviembre de 2026, permite a un atacante dentro de una máquina virtual invitada tomar el control del proceso del host que gestiona esa VM sin provocarle fallos ni alertar a las herramientas estándar de monitorización.

Qué ocurrió

El equipo de investigación, publicando bajo PWN.AI Security Research, lanzó la segunda parte de su serie "PwnEscape". Este trabajo se basa en un primitivo de memoria previamente revelado que permitía a la invitada leer y escribir en memoria física seleccionada del host. En esta continuación, encadenaron ese primitivo con una técnica para localizar y modificar el estado de ejecución activo del proceso Firecracker en el host. El objetivo era Firecracker versión 1.16.1 ejecutándose en un sistema x86-64 con el kernel de Linux 7.0.0-1011-aws.

El exploit no depende de desbordamientos de búfer tradicionales ni de errores de software en la lógica de la aplicación. En cambio, abusa del mecanismo por el cual el kernel de Linux guarda y restaura el estado del procesador al cambiar entre la VM invitada y el proceso de espacio de usuario del host. Al identificar la ubicación exacta de memoria donde se almacenan los registros del hilo del host durante una salida de KVM, los atacantes redirigieron el flujo de ejecución. Forzaron al proceso del host a ejecutar una llamada al sistema write, imprimiendo una cadena de marcador específica en su flujo de error estándar. Crucialmente, después de ejecutar esta carga útil, el exploit restauró los valores originales de los registros, permitiendo que el proceso Firecracker continuara ejecutándose normalmente. La VM permaneció accesible vía SSH y no se registraron errores en el kernel del host.

Cómo funciona

El núcleo del ataque se basa en comprender cómo interactúan las CPUs virtuales (vCPUs) con el host. Cada vCPU en una microVM de Firecracker corresponde a un hilo en el proceso del host. Cuando la invitada necesita realizar una operación que requiere intervención del host, como manejar una interrupción o acceder a hardware emulado, el hilo sale del módulo del kernel KVM y regresa al espacio de usuario. Durante esta salida, el kernel guarda el estado actual del hilo, incluido el puntero de instrucción y el puntero de pila, en una estructura llamada pt_regs.

Los atacantes utilizaron su primitivo existente de acceso a memoria para escanear la memoria física del host en busca de estas estructuras de registros guardadas. Primero, colocaron un patrón de bytes único, o nonce, en una página conocida de la invitada. Recorriendo las Tablas de Páginas Extendidas (EPT), tradujeron la dirección física de la invitada a una dirección física del host. A continuación, realizaron una asignación inversa de las tablas de páginas del host para encontrar qué proceso del host había mapeado esa página física, identificando así efectivamente el proceso Firecracker y su diseño de memoria a pesar de la Aleatorización de la Disposición del Espacio de Dirección (ASLR).

Una vez identificado el proceso, buscaron un marco pt_regs que coincidiera con el estado esperado de un hilo que regresaba de una llamada ioctl KVM_RUN. Validaron los candidatos comprobando el puntero de instrucción guardado contra direcciones de código conocidas de Firecracker y asegurándose de que los argumentos de la syscall coincidieran con una solicitud KVM activa. Tras localizar el marco correcto, modificaron el puntero de instrucción guardado para apuntar a un wrapper write en el binario de Firecracker y ajustaron el puntero de pila para incluir sus argumentos de carga útil. Cuando la invitada provocó una salida de KVM escribiendo en el puerto serie, el hilo del host reanudó la ejecución en la dirección controlada por el atacante, ejecutó la escritura y luego regresó a su ruta original mediante una secuencia de retorno cuidadosamente construida.

Detalles clave

• Entorno objetivo: Firecracker v1.16.1 en x86-64, kernel del host 7.0.0-1011-aws, kernel de la invitada 6.18.44+.
• Nivel de privilegio: El exploit logró la ejecución de código como root porque la instancia de prueba se lanzó directamente como root sin un jailer ni restricciones de namespace.
• Sigilo: La VM permaneció totalmente operativa tras el exploit; las conexiones SSH persistieron y los contadores de tiempo de actividad continuaron normalmente.
• Primitivo de memoria: El ataque requiere una capacidad previa para leer y escribir páginas específicas de memoria física del host desde dentro de la invitada.
• Validación: Los investigadores confirmaron el éxito capturando la cadena de marcador N8V23M2\n del stderr del proceso del host mientras verificaban que el texto ejecutable y las bibliotecas compartidas permanecían sin modificaciones.
• Recuperación: El exploit restaura explícitamente tres palabras de pila modificadas tras la ejecución, dejando sin rastros forenses inmediatos en el área temporal de la pila.

Por qué importa

Para los ingenieros que construyen plataformas serverless o entornos de contenedores aislados, esta demostración destaca los riesgos de confiar únicamente en los límites del hipervisor para la seguridad. Firecracker está diseñado para un aislamiento de alta densidad, pero este exploit muestra que si una invitada puede romper la capa de aislamiento de memoria, puede secuestrar el propio hilo de gestión. Esto es particularmente peligroso porque el ataque no provoca fallos en el servicio, lo que dificulta su detección mediante monitores estándar de disponibilidad.

El impacto depende en gran medida de la configuración de despliegue. Los investigadores señalaron que su entorno de pruebas ejecutaba Firecracker como root sin capas adicionales de contención como filtros seccomp o user namespaces. En entornos de producción, estos controles limitan lo que un atacante puede hacer incluso si logra ejecutar código. Sin embargo, la capacidad de redirigir el flujo de ejecución dentro del proceso VMM sigue siendo una amenaza grave, ya que podría permitir a los atacantes evadir políticas seccomp si pueden manipular los argumentos de las syscalls o saltar a cadenas de gadgets dentro del espacio de memoria permitido.

Qué puedes hacer

• Auditar niveles de privilegio: Asegúrate de que los procesos de Firecracker no se ejecuten como root. Utiliza el jailer integrado para reducir privilegios y restringir el acceso al sistema de archivos inmediatamente al iniciar.
• Habilitar filtros seccomp: Configura perfiles seccomp estrictos para limitar las syscalls disponibles para el proceso Firecracker, reduciendo la superficie de ataque ante cualquier posible ejecución de código.
• Utilizar user namespaces: Ejecuta Firecracker dentro de user namespaces para aislar el proceso del usuario root del host, limitando el impacto de cualquier fuga.
• Monitorizar comportamiento anómalo: Implementa registro de eventos para salidas inesperadas en stderr o patrones inusuales de syscalls desde los procesos VMM, aunque este exploit está diseñado para ser sigiloso.
• Mantente actualizado: Sigue las actualizaciones del proyecto Firecracker y aplica parches relacionados con el aislamiento de memoria y el manejo de interacciones KVM tan pronto como estén disponibles.
• Revisar primitivos de memoria: Investiga cómo tu carga de trabajo podría exponer mapeos de memoria física del host a las invitadas y refuerza esas interfaces contra búsquedas de traducción no autorizadas.