Cloudflare corrigió una vulnerabilidad en sus contenedores que permitía a algunos usuarios leer datos residuales de otros clientes almacenados en discos compartidos. El fallo ocurría porque el sistema no borraba completamente los bloques de almacenamiento antes de reasignarlos. La empresa ya solucionó el problema y no encontró evidencia de que haya sido explotado maliciosamente.





Un fallo en Cloudflare Containers permitió que un cliente de pago leyera datos que los contenedores de otros clientes habían dejado en el mismo servidor, según informaron Cloudflare y los investigadores que lo descubrieron el jueves.

Los datos provenían de un espacio de disco que contenedores anteriores habían utilizado y liberado, no de ninguna carga de trabajo activa, y un atacante no podía elegir de quién eran los datos que obtenía, según Cloudflare. La empresa ha corregido el fallo en todo su servicio y afirma que tú no necesitas hacer nada.

Cloudflare Containers ejecuta los programas de los clientes dentro de contenedores en servidores compartidos por muchas cuentas, y Cloudflare, no el cliente, elige el servidor. Cloudflare Sandboxes, que se ejecuta sobre Containers y se vende como un lugar seguro para ejecutar código no confiable, incluido el escrito por agentes de IA, también se vio afectado.

El fallo fue reportado el 4 de septiembre por Oren Yomtov, de la empresa de seguridad Accomplish, a través del programa de recompensas por errores de Cloudflare.

El problema residía en cómo estaban configurados los discos compartidos. Cada contenedor obtiene un disco construido mediante una función de Linux llamada thin provisioning, que asigna el almacenamiento en bloques de 64 kilobytes. Cuando se eliminaba un contenedor, sus bloques volvían a un grupo compartido entre las cuentas de los clientes.

Ese grupo estaba configurado para omitir la limpieza de un bloque antes de entregarlo al siguiente contenedor, siendo que la limpieza es normalmente la opción predeterminada. Por lo tanto, cuando un nuevo contenedor escribía solo una pequeña cantidad en un bloque reutilizado, el resto del bloque aún contenía los datos del contenedor anterior.

Para acceder a ellos, los investigadores escribieron un pequeño bloque de cuatro kilobytes en el espacio no utilizado y luego leyeron el bloque completo al nivel de disco bruto. Los 60 kilobytes que no habían escrito todavía contenían bytes de un contenedor anterior.

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, dijo Cloudflare; el propio informe de los investigadores (Accomplish) enumera listados de directorios, bases de datos SQLite, perfiles de navegador Chromium, archivos .env y archivos de credenciales, describiéndolos como archivos de otros clientes.

Los investigadores informaron que sus scripts de análisis solo generaron recuentos y comprobaciones de formato, no contenidos de archivos, y que el material que enviaron a Cloudflare no contenía nombres, identificadores, credenciales ni contenido recuperado de terceros.

También confirmaron que los datos recuperados se mantuvieron privados y se eliminaron de forma segura después de enviarlos, dijo Cloudflare. Los investigadores no demostraron que el fallo pudiera cambiar los datos activos de otro cliente o dejar fuera de servicio una carga de trabajo.

Cloudflare solucionó el fallo en dos pasos. Primero, volvió a activar la limpieza para 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 mapeados en los discos de contenedores en ejecución o en la caché de capas de imágenes preparadas de cada servidor, que un nuevo contenedor podría heredar y leer. Por lo tanto, Cloudflare también retiró cada disco de contenedor en ejecución y borró esas cachés, vaciando y reiniciando los servidores durante las horas de menor actividad. Terminó esa limpieza el 19 de septiembre y reveló el fallo cinco días después.

Cloudflare dijo que buscó indicios 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 su propia copia del ataque, y las ejecutó contra los registros de actividad de disco que había mantenido. Solo encontró las pruebas autorizadas de los investigadores y de sus propios ingenieros, y afirmó que no vio evidencia de que este método específico fuera utilizado por nadie más.

Ese hallazgo cubre los registros que Cloudflare conservó, aunque no indicó el lapso de tiempo ni cuándo se implementó por primera vez la configuración insegura, por lo que no está claro cuánto duró la exposición según su relato.

Los investigadores, quienes afirman por separado que la misma configuración de disco afectó al producto Browser Run de Cloudflare, describieron el fallo como su sexta fuga de un sandbox de código publicada desde julio, después de 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.

Fuente:
THN