Un fallo en Cloudflare Containers permitía a un cliente de pago acceder a información residual dejada en el disco por contenedores de otros clientes en el mismo servidor, según informaron el jueves Cloudflare y los investigadores que lo descubrieron.
Los datos provenían de espacio en disco que contenedores anteriores habían utilizado y liberado, no de cargas de trabajo activas, y un atacante no podía elegir de qué cliente obtenía la información, según Cloudflare. La compañía ha corregido el fallo en todo su servicio y afirma que los clientes no necesitan hacer nada.
Cloudflare Containers ejecuta los programas de los clientes dentro de contenedores en servidores compartidos por múltiples cuentas, y es Cloudflare, no el cliente, quien elige el servidor. Cloudflare Sandboxes, que funciona sobre Containers y se comercializa como un entorno seguro para ejecutar código no confiable, incluido el código generado por agentes de IA, también se vio afectado.
El fallo fue reportado el 4 de septiembre por Oren Yomtov, de la firma de seguridad Accomplish, a través del programa de recompensas por errores de Cloudflare.
El problema residía en la configuración de los discos compartidos. Cada contenedor recibe un disco creado con una característica de Linux llamada aprovisionamiento fino (thin provisioning), que asigna almacenamiento en bloques de 64 kilobytes. Cuando se eliminaba un contenedor, sus bloques volvían a un grupo compartido entre cuentas de clientes.
Ese grupo estaba configurado para omitir el borrado de un bloque antes de entregarlo al siguiente contenedor, cuando lo normal es que el borrado sea la opción predeterminada. Así, cuando un nuevo contenedor escribía solo una pequeña cantidad en un bloque reutilizado, el resto del bloque aún contenía datos del contenedor anterior.
Para acceder a ellos, los investigadores escribieron un pequeño bloque de cuatro kilobytes en espacio no utilizado y luego leyeron el bloque completo a nivel de disco sin procesar. Los 60 kilobytes que no habían escrito aún contenían bytes de un contenedor previo.
En pruebas de producción, informaron haber encontrado material residual en 18 de 24 intentos, cada uno en un servidor elegido por Cloudflare, y en 20 de 22 máquinas subyacentes en cuatro continentes.
Los bloques recuperados contenían estructuras de directorios, páginas de bases de datos y bases de datos SQLite estructuralmente completas, según Cloudflare; el informe de los investigadores enumera listados de directorios, bases de datos SQLite, perfiles de navegador Chromium, archivos .env y archivos de credenciales, y los describe como archivos de otros clientes.
Los investigadores informaron que sus scripts de análisis solo generaban recuentos y comprobaciones de formato, no contenidos de archivos, y que el material que enviaron a Cloudflare no contenía nombres de terceros, identificadores, credenciales ni contenido recuperado.
También confirmaron que los datos recuperados se mantuvieron privados y se eliminaron de forma segura después de enviarlos, según Cloudflare. Los investigadores no demostraron que el fallo pudiera modificar datos activos de otro cliente o dejar fuera de servicio una carga de trabajo.
Cloudflare corrigió el fallo en dos pasos. Primero reactivó el borrado de los bloques recién entregados, lo que detuvo el método reportado; los investigadores confirmaron el 14 de septiembre que su prueba de concepto ya no funcionaba.
Pero ese cambio no limpió los bloques ya asignados a discos de contenedores en ejecución ni a la caché de capas de imágenes preparadas de cada servidor, que un nuevo contenedor podía heredar y leer. Por ello, Cloudflare también retiró todos los discos de contenedores en ejecución y borró esas cachés, drenando y reiniciando servidores durante horas de baja actividad. Terminó esa limpieza el 19 de septiembre y reveló el fallo cinco días después.
Cloudflare afirmó que buscó señales de que alguien más hubiera utilizado el método. Creó firmas de detección a partir de la prueba de concepto de los investigadores y de su propia copia del ataque, y las ejecutó contra los registros de actividad de disco que había conservado. Solo encontró las pruebas autorizadas de los investigadores y de sus propios ingenieros, y dijo que no vio evidencia de que este método específico fuera utilizado por nadie más.
Ese hallazgo abarca los registros que Cloudflare conservó, aunque no especificó el periodo de tiempo ni cuándo se estableció por primera vez la configuración insegura, por lo que la duración de la exposición no queda clara en su relato.
Los investigadores, que por separado afirman que la misma configuración de disco afectó al producto Browser Run de Cloudflare, describieron el fallo como su sexta evasión de una sandbox de código publicada desde julio, tras hallazgos en Claude Cowork y Claude Code de Anthropic, la herramienta de línea de comandos de Cursor, Docker y Codex de OpenAI. La publicación de Cloudflare nombró a Containers y Sandboxes como afectados y no mencionó Browser Run.
Deja una respuesta