Vercel Sandbox resiste el hackeo: 1285 informes, $242 000 y un bug en el kernel de Linux

Vercel ha cerrado el desafío de hacking en torno a Vercel Sandbox, su entorno en la nube para ejecutar código de forma aislada. En dos semanas, los investigadores enviaron 1285 informes y Vercel pagó $242 000 en recompensas. Ningún informe demostró acceso a datos de clientes. Sin embargo, el hallazgo más grave no estaba en el código de Vercel, sino en la base sobre la que se apoya buena parte de las nubes: una vulnerabilidad de día cero en la pila de red del kernel de Linux.

Un zero-day al tercer día

El informe principal llegó al tercer día del programa. Paulos Yibelo (pwn.ai), investigador de HackerOne, trabajó desde una sandbox corriente, sin privilegios especiales. Encontró un defecto en la pila de red del kernel de Linux: paquetes especialmente construidos y enviados desde dentro de una microVM permitían llevar a cabo tres ataques distintos.

• Fuga de memoria del host por la red. La memoria de la máquina, que la sandbox comparte con otros inquilinos, acababa en los paquetes que el invitado enviaba a internet. La fuga era continua mientras el invitado siguiera enviando tráfico. El ataque se demostró en sandboxes de producción de Vercel.
• Caída del host. Bastaban dos paquetes para tumbar la máquina y, con ella, todas las sandboxes que se ejecutaban en ella.
• Ejecución de código en el host. El mismo fallo permitía lanzar comandos con privilegios completos de administrador y salir de los límites del aislamiento.

El investigador reprodujo la caída y la ejecución de código en máquinas propias con KVM y Firecracker, que replican la configuración de Vercel Sandbox.

Casi todos los grandes proveedores de nube aíslan a sus clientes precisamente en esta capa del kernel, por lo que el riesgo afecta a la infraestructura compartida. Vercel afirma que trabajó con el investigador, así como con AWS y otros socios, para acelerar la corrección. En paralelo, Yibelo contactó con los mantenedores del kernel y preparó con ellos candidatos a parche. Estos pasan por una revisión privada, aún no se han asignado CVE y no se divulgan los detalles. La compañía comunicó la existencia de la vulnerabilidad porque ya se hablaba de ella en público.

La mirada desde dentro: un becario y Trail of Bits

Además de la caza pública de recompensas, Vercel realizó auditorías internas con acceso completo al código fuente y contrató a Trail of Bits. No todos los hallazgos llegaron de fuera. Marcos Hernanz, becario de Vercel, descubrió una fuga entre inquilinos en la capa de almacenamiento de datos de Linux device-mapper: cualquier sandbox podía leer bloques de disco reutilizados de sandboxes eliminadas previamente.

Trail of Bits dedicó cuatro semanas-ingeniero, con dos especialistas asignados. Tuvieron acceso completo a los repositorios y a dos entornos de prueba corporativos. El resultado fue de 20 hallazgos, cada uno probado, confirmado y vinculado a un punto concreto del código. La revisión de arquitectura mostró que la frontera de virtualización es sólida. Cada sandbox se ejecuta en una microVM Firecracker independiente con su propio kernel invitado, el modelo de dispositivos es mínimo a propósito y ningún invitado comparte el kernel en ejecución ni con el host ni con otro inquilino.

Tres conclusiones estructurales

Los auditores hicieron tres recomendaciones y Vercel asegura que las ha aplicado todas.

• Eliminar la confianza en el invitado. La capa de control aceptaba valores devueltos por el software dentro de la microVM, y cualquiera de esos valores lo introduce, en la práctica, el inquilino. Ahora todo lo que cruza la frontera se calcula en el servidor o se firma con una clave a la que el invitado no tiene acceso.
• Una política, un árbitro. El control del tráfico saliente estaba repartido entre varios subsistemas, y cada uno interpretaba por su cuenta la política de red, de modo que sus decisiones no siempre coincidían. Ahora hay un único procedimiento de canonicalización por cada tipo de dato y un único componente por cada decisión, y las conexiones se vuelven a comprobar cuando cambia la política.
• Partir de la base de que aparecerá el próximo zero-day. Se reforzó la protección alrededor de cada sandbox para limitar el daño si se vulnera el software de virtualización. Los kernels de los hosts se actualizan, la virtualización anidada está desactivada y el jailer de Firecracker lanza cada proceso de la microVM con privilegios reducidos.

Lecciones prácticas para quien ejecuta código ajeno

Las sandboxes para agentes de IA y código generado se están convirtiendo en una pieza estándar del stack, y este caso muestra dónde está realmente el riesgo. La microVM con kernel propio funcionó: incluso con una vulnerabilidad en el host, nadie accedió a datos de clientes. Pero el aislamiento no elimina la necesidad de actualizar los kernels de los hosts ni de desconfiar de todo lo que devuelve el invitado.

Los equipos que construyen sus propias sandboxes o eligen proveedor deberían comprobar tres cosas: si la capa de control acepta datos del invitado sin verificarlos, si el análisis de las políticas de red está duplicado en distintos componentes y con qué rapidez despliega el proveedor los parches del kernel. Los detalles de los CVE se conocerán cuando se publiquen las correcciones, y entonces habrá que revisar las versiones de kernel propias y las configuraciones de Firecracker.