Estudio revela variante remota de Spectre que filtra un JWT en memoria de Cloudflare Worker

Investigadores en seguridad han publicado un experimento controlado que demuestra una variante remota de Spectre capaz de filtrar un JSON Web Token (JWT) alojado en la memoria de otro Cloudflare Worker co-localizado dentro del mismo proceso, con una tasa máxima de exfiltración de hasta 12 bits por segundo. En la prueba de extremo a extremo los autores ejecutaron un Worker atacante y un Worker “víctima” bajo su control y colocaron deliberadamente el JWT en la memoria del segundo para medir el canal. Cloudflare confirmó que, en ese experimento, no se accedió a datos de clientes y que ya desplegó mitigaciones en producción; la compañía también declaró no haber encontrado indicadores de explotación activa durante los últimos tres años.

Hecho comprobado: la técnica se basa en una versión de las llamadas “transient execution” o ataques Spectre, donde lecturas especulativas y microarquitecturales se convierten en canales laterales de tiempo para filtrar bits desde otra ejecución. En el entorno de Cloudflare Workers esto sólo es posible si el atacante y la víctima terminan co-localizados en diferentes V8 isolates dentro del mismo proceso. El trabajo de los investigadores describe dos factores clave que facilitaron la fuga: primero, que un canal de temporización remoto era posible usando WebSockets (los Workers no exponen fuentes locales de temporización de alta resolución); segundo, que las Durable Objects permiten que un isolate permanezca activo durante horas, evitando que la política de aislamiento dinámico (DyPrIs) reasigne inmediatamente el código a un proceso separado.

Técnicamente, el ataque no requiere ejecutar código nativo ni una vulnerabilidad de V8 o “escape” del sandbox: el adversario ejecuta código legítimo desde su propio isolate y explota señales microarquitecturales (como estados del iTLB y predictores de ramas) para inducir y medir efectos observables a través de una conexión remota. Los investigadores documentaron además que cargas intensivas en I/O por WebSockets incrementan la actividad del iTLB y atenúan la señal de detección usada por DyPrIs —la heurística de Cloudflare para decidir cuándo mover un isolate sospechoso a otro proceso—. Según el paper, esa reducción de la señal permitió que la detección no disparase mientras la fuga ocurría.

Confirmado por Cloudflare: Workers ejecutan múltiples tenants en isolates V8 dentro del mismo proceso con el objetivo de reducir latencia de arranque, y su defensa DyPrIs mueve isolates sospechosos a procesos separados después de una invocación. Tras la divulgación, Cloudflare describe haber ampliado DyPrIs, integrado el “V8 Sandbox” (limita acceso transitorio a punteros de 64 bits) y desplegado un esquema de aislamiento en proceso basado en Memory Protection Keys (MPK) —una característica de CPU que permite proteger regiones de memoria con claves de hardware— para reducir la posibilidad de lectura cruzada entre heaps de isolates.

Datos reproducibles del estudio: los experimentos se realizaron en servidores Linux con procesadores AMD EPYC Zen 2 y Zen 3; para obtener la tasa máxima de exfiltración los autores trabajaron en ventanas de baja carga (10–25% CPU nocturna), y reportaron una precisión del 99.16% en la recuperación de bits a la máxima tasa. Los autores aclaran que con mayor carga de sistema la velocidad disminuye, pero la técnica sigue siendo viable aunque más lenta. Comparación histórica: el ataque remoto previo contra Workers, publicado en 2021 por Cloudflare y TU Graz, alcanzó unas 120 bits por hora (~2 bits/minuto); la nueva medición representa una mejora significativa en tasa (hasta unas 360 veces más rápida en condiciones controladas).

Qué significa esto para usuarios de Workers y servicios en la nube: en términos prácticos, la técnica demuestra que bajo ciertas condiciones un actor con código legítimo desplegado en la misma plataforma puede —teóricamente— extraer secretos alojados en memoria de otros tenants. En la prueba se filtró un JWT, un tipo de secreto que puede permitir acceso API o validaciones de sesión si no está acotado en tiempo. Aunque la capacidad de exfiltrar decenas de bits por segundo todavía implica un proceso relativamente lento para obtener secretos largos, la automatización y repetición permiten reconstruir claves o tokens con el tiempo.

Qué está confirmado y qué sigue incierto: está confirmado que la técnica funciona en laboratorio contra la configuración de producción previa al parche, y que Cloudflare ha desplegado mitigaciones. No está confirmado que haya ocurrido explotación en clientes reales; Cloudflare reporta no encontrar indicadores en los últimos tres años. Es incierto hasta qué punto las mitigaciones (combinación de DyPrIs mejorado, V8 Sandbox y MPK) eliminan toda la explotación práctica en todos los escenarios y arquitecturas, y cuánto impacto de rendimiento o compatibilidad tendrán a escala.

Consecuencias reales posibles: para cargas que mantengan Workers largos en memoria (por ejemplo, Durable Objects con invocaciones prolongadas) o que usen WebSockets intensivos, existe un riesgo mayor de co-localización explotable. Secretos de larga duración guardados en memoria de Workers (claves API, JWT con TTL amplios, credenciales en variables globales) son los activos más vulnerables. Para entornos multi-tenant donde la co-localización es común, este tipo de canal subraya la tensión entre optimización de latencia y aislamiento purista por proceso.

Recomendaciones concretas para desarrolladores y administradores: en primer lugar, trate los secretos como de corta duración: reduzca TTL de tokens, rote claves críticas con frecuencia y aplique limits de scope. Evite mantener secretos sensibles en variables globales en Workers; utilice bindings de secretos gestionados y servicios externos con comprobaciones adicionales (por ejemplo, OAuth con refresh controlado). Para arquitecturas que usan Durable Objects o conexiones WebSocket, considere acotar el tiempo de vida de invocaciones largas o fragmentar estado para minimizar superficies en memoria. Active y revise las políticas y logs de su proveedor para detectar co-localizaciones inusuales o patrones de WebSocket largos. Si maneja datos muy sensibles, evalúe exigir ejecución en entornos con aislamiento por proceso o instancias dedicadas.

Recomendaciones para operadores de plataformas: implemente detección en tiempo real durante la ejecución (no solo post-invocación), y emplee señales que no puedan ser fácilmente amortiguadas por actividad de I/O. Combinar protecciones hardware como MPK con sandboxing de V8 y layouts de memoria rotativos reduce la probabilidad de que dos isolates compartan la misma clave de protección, pero esas medidas deben evaluarse frente a cargas reales y en múltiples arquitecturas de CPU. Mantenga auditorías y búsquedas proactivas de patrones de temporización remota que usen WebSockets como canal y limite la exposición de conexiones persistentes cuando no sean necesarias.

Fuentes y lectura adicional: explicación técnica original de Spectre https://spectreattack.com/spectre.pdf, y la documentación de Cloudflare Workers para entender el modelo operativo de isolates y Durable Objects https://developers.cloudflare.com/workers/. Para detalles sobre Memory Protection Keys en CPU x86, consulte la guía de Intel sobre MPK https://www.intel.com/content/www/us/en/developer/articles/technical/memory-protection-keys.html.

En resumen: la investigación reabre la discusión sobre la seguridad de ofrecer aislamiento a nivel de lenguaje (V8 isolates) dentro de un mismo proceso para optimizar latencia. Las mitigaciones desplegadas por Cloudflare reducen la superficie de ataque, pero la responsabilidad compartida recae también en desarrolladores y operadores: minimizar tiempos de vida de secretos, evitar patrones de ejecución largos en memoria y auditar uso intensivo de WebSockets son pasos prácticos que limitan la exposición mientras se continúa evaluando la eficacia de las protecciones a escala.