Investigadores de seguridad han revelado los detalles de un ataque Spectre remoto contra Cloudflare Workers que logró filtrar un JSON Web Token (JWT) de un Worker co-ubicado en el entorno de producción a una velocidad de hasta 12 bits por segundo, 360 veces más rápida que un ataque demostrado en 2021. El experimento de extremo a extremo utilizó un Worker atacante y un Worker víctima controlados por los investigadores, con el JWT colocado intencionalmente en la memoria de la víctima. El artículo de investigación afirmó que no se accedió a datos de clientes.
Contexto y vulnerabilidad
Cloudflare Workers ejecuta código de múltiples inquilinos en isolates V8 separados dentro del mismo proceso del sistema operativo, confiando en el aislamiento a nivel de lenguaje en lugar de un estricto aislamiento de procesos para reducir la latencia de arranque. Una lectura de memoria dentro de un proceso Worker compartido puede conducir a una fuga entre inquilinos, según Cloudflare. El ataque requiere que el Worker atacante y el Worker víctima estén co-ubicados en isolates V8 separados dentro del mismo proceso Worker.
El atacante controla código válido en su propio isolate. La ejecución de código nativo está fuera del modelo de amenaza, y el ataque no depende de una explotación de software V8 ni de un escape de la sandbox. Cloudflare afirmó que Workers restringen las fuentes de sincronización locales congelando o refinando los temporizadores durante la ejecución de la CPU, y no exponen memoria compartida ni multihilo a los scripts de Workers.
Hallazgos de los investigadores
Los investigadores descubrieron que las comunicaciones WebSocket podrían proporcionar una fuente de sincronización remota, mientras que los Durable Objects podían mantener vivo un isolate de Worker durante cinco a más de 20 horas. DyPrIs aísla scripts sospechosos en un proceso separado después de que finaliza una invocación, y los investigadores encontraron que una invocación de Durable Object de larga duración podía continuar ejecutándose antes de que se llevara a cabo el aislamiento.
También descubrieron que la actividad de entrada/salida (E/S) con mucho uso de WebSocket aumentaba la actividad del búfer de traducción de instrucciones (iTLB), reduciendo la señal normalizada de predicción errónea de ramas utilizada por DyPrIs por debajo de su umbral de detección. Cloudflare describió el problema como una limitación en su implementación de DyPrIs, mientras que el artículo indicó que las dos debilidades reflejan limitaciones fundamentales del enfoque de detección, más que descuidos de implementación. Los investigadores sugirieron que una detección robusta debería producirse durante la ejecución y utilizar una señal que no pueda ser suprimida por la actividad de E/S.
El artículo indicó que las pruebas de producción se realizaron en servidores Linux con procesadores AMD EPYC Zen 2 y Zen 3, y que los investigadores realizaron las mediciones intencionalmente durante la noche, cuando la utilización de la CPU estaba entre el 10% y el 25%, para observar los mejores resultados posibles. Los investigadores señalaron que una mayor carga del sistema reducía la tasa de fuga, aunque los ataques más lentos seguían siendo factibles bajo alta carga. El artículo informó de una fuga de hasta 12 bits por segundo con una precisión del 99,16%, en comparación con los 2 bits por minuto del ataque anterior.
Respuesta de Cloudflare y mitigaciones
Cloudflare declaró que el ataque ya ha sido mitigado en producción después de mejorar el Aislamiento Dinámico de Procesos (DyPrIs), integrar la V8 Sandbox y desplegar aislamiento en proceso basado en Memory Protection Keys (MPK). La compañía añadió que no encontró indicios de explotación activa en los últimos tres años. Sin embargo, los investigadores afirmaron en el artículo: 'Demostramos que la implementación en producción de DyPrIs era insuficiente'.
- Mejora de DyPrIs: mejora las capacidades de detección del mecanismo de aislamiento existente.
- V8 Sandbox: limita el acceso transitorio a punteros de 64 bits.
- Aislamiento en proceso basado en MPK: coloca los montones de Workers detrás de claves de protección de hardware. Cloudflare indicó que los sistemas x64 modernos dejan alrededor de 12 claves disponibles para este propósito, y su diseño combina las claves con la V8 Sandbox y un diseño de memoria rotativo para evitar que sandboxes cercanos compartan una clave.
La descripción de Cloudflare de septiembre de 2025 indicaba que la asignación aleatoria de MPK por sí sola atraparía alrededor del 92% de los accesos entre isolates, porque dos isolates pueden recibir la misma clave, y que el diseño rotativo más estricto se utiliza para eliminar esa brecha para el modelo de amenaza cubierto dentro de la sandbox.
La divulgación llega casi cinco años después de que Cloudflare y la Universidad Tecnológica de Graz (TU Graz) publicaran una investigación que demostraba un ataque Spectre remoto contra Workers a 120 bits por hora e introdujera DyPrIs como defensa. El artículo anterior informó de una tasa de falsos positivos del 0,61% y concluyó que DyPrIs proporcionaba estadísticamente las mismas garantías de seguridad que el aislamiento estricto de procesos contra los ataques Spectre evaluados en ese momento.
Deja una respuesta