Una configuración hizo que Cloudflare entregara a contenedores datos de disco de otros usuarios

Un contenedor eliminado debería desaparecer junto con sus datos temporales, pero en la infraestructura de Cloudflare parte de la información pudo sobrevivir al propietario anterior del bloque de disco. La empresa corrigió una vulnerabilidad en Cloudflare Containers que permitía a un cliente con una cuenta de pago de Workers obtener fragmentos de datos de contenedores de otros clientes que habían funcionado anteriormente en el mismo servidor físico.

Cloudflare Containers ejecuta cada carga de trabajo dentro de una máquina virtual Firecracker independiente y le proporciona un disco virtual a través de Linux device mapper con un mecanismo de thin provisioning. Esta arquitectura ahorra espacio, asignando bloques físicos solo cuando se escriben. El problema afectó precisamente a esta capa de almacenamiento, y no a una fuga clásica desde el contenedor.

Los discos se dividían en bloques de 64 KiB. Tras eliminar un contenedor, los bloques ocupados volvían al grupo común y podían asignarse a otro cliente. En la configuración de Cloudflare existía el parámetro skip_block_zeroing, que desactivaba el borrado del bloque antes de volver a asignarlo.

Los especialistas de Accomplish mostraron un escenario simple. Un contenedor nuevo escribía solo 4 KiB en un área libre, recibía un bloque físico usado anteriormente y luego leía los 64 KiB directamente desde el dispositivo. La nueva escritura reemplazaba los primeros 4 KiB, y los 60 KiB restantes podían contener datos de terceros. El caso vuelve a mostrar cuán críticos son los detalles de aislamiento en entornos donde clientes independientes operan en la misma infraestructura.

Durante las pruebas de producción, se encontraron datos residuales en 18 de 24 despliegues y en 20 de 22 nodos físicos en cuatro regiones del mundo. Entre los fragmentos recuperados había estructuras de directorios, páginas de bases de datos y bases SQLite completas. La comprobación del sistema de archivos también reveló 2700 inodos de directorios que pertenecían a sistemas de archivos de terceros.

El ataque no permitía elegir a un cliente, servidor o conjunto de archivos concretos ni daba acceso al disco activo de otro contenedor. Los especialistas tampoco demostraron la posibilidad de modificar datos de terceros o de interrumpir el funcionamiento de una carga de trabajo. Cloudflare revisó el historial disponible de operaciones de disco y no encontró indicios de explotación fuera de las pruebas de Accomplish y de sus propios ingenieros. Problemas como este son especialmente sensibles para una gran plataforma en la nube, en torno a la cual ya se habían planteado preguntas sobre los límites de protección entre clientes.

Oren Yomtov de Accomplish informó de la vulnerabilidad el 4 de septiembre a través del programa de recompensas de Cloudflare. La compañía desactivó skip_block_zeroing y, para el 7 de septiembre, desplegó la primera corrección, pero un solo cambio de configuración resultó insuficiente. Los bloques antiguos permanecían enlazados a discos activos y a capas de imágenes en caché, por lo que Cloudflare también volvió a crear los discos, limpió las cachés y reinició las máquinas virtuales. La limpieza completa la terminó la compañía el 19 de septiembre. Según el análisis técnico de Cloudflare, los clientes no necesitan hacer cambios por su cuenta.

Unos días antes de la divulgación de esta vulnerabilidad surgió una cuestión similar sobre la fiabilidad del aislamiento en torno a Docker Sandboxes. Un error permitía que el código dentro de la sandbox saliera del directorio permitido y accediera a archivos del host macOS, lo que volvió a mostrar el coste de un límite débil en un entorno aislado.

La propia infraestructura de Cloudflare estuvo recientemente implicada en otro gran incidente. Una clave de API robada permitió a los atacantes desplegar un Worker y usar la plataforma confiable para infectar aproximadamente 100.000 sitios.

En enero surgió otra historia arquitectónica alrededor de Cloudflare. Un especialista descubrió un comportamiento controvertido de Universal SSL y CAA que podría haber debilitado las restricciones sobre la emisión de certificados para millones de dominios.