Estudo revela variante remota de Spectre que filtra um JWT em memória do Cloudflare Worker

Pesquisadores em segurança publicaram um experimento controlado que demonstra uma variante remota de Spectre capaz de filtrar um JSON Web Token (JWT) hospedado na memória de outro Cloudflare Worker co-localizado dentro do mesmo processo, com uma taxa máxima de exfiltração de até 12 bits por segundo. No teste extremo a extremo os autores executaram um Worker atacante e um Worker “vítima” sob seu controle e colocaram deliberadamente o JWT na memória do segundo para medir o canal. Cloudflare confirmou que, nesse experimento, não se concordou com dados de clientes e que já desencadeou mitigações em produção; a empresa também declarou não ter encontrado indicadores de exploração ativa durante os últimos três anos.

Feito comprovado: a técnica baseia-se numa versão das chamadas “transient execution” ou ataques Spectre, onde leituras especulativas e microarquitecturais se tornam canais laterais de tempo para filtrar bits a partir de outra execução. No ambiente do Cloudflare Workers isso só é possível se o atacante e a vítima terminam co-localizados em diferentes V8 isolates dentro do mesmo processo. O trabalho dos pesquisadores descreve dois fatores chave que facilitaram a fuga: primeiro, que um canal de temporização remoto era possível usando WebSockets (os Workers não expõem fontes locais de temporização de alta resolução); segundo, que as Durable Objects permitem que um isolate permaneça ativo durante horas, evitando que a política de isolamento dinâmico (DyPrIs) reasigne imediatamente o código a um processo separado.

Tecnicamente, o ataque não requer executar código nativo ou uma vulnerabilidade de V8 ou “escape” do sandbox: o adversário executa código legítimo desde sua própria isolate e explora sinais microarquitecturais (como estados do iTLB e preditores de ramos) para induzir e medir efeitos observáveis através de uma conexão remota. Os pesquisadores documentaram ainda que cargas intensivas em I/O por WebSockets incrementam a atividade do iTLB e atenuam o sinal de detecção usado por DyPrIs - a heurística de Cloudflare para decidir quando mover um isolate suspeito para outro processo. Segundo o paper, essa redução do sinal permitiu que a detecção não disparasse enquanto a fuga ocorria.

Confirmado por Cloudflare: Workers executa múltiplos tenants em isolates V8 dentro do mesmo processo com o objetivo de reduzir latência de arranque, e sua defesa DyPrIs move isolates suspeitos a processos separados após uma invocação. Após a divulgação, Cloudflare descreve ter ampliado DyPrIs, integrado o “V8 Sandbox” (limita acesso transitório a ponteiros de 64 bits) e implantado um esquema de isolamento em processo baseado em Memory Protection Keys (MPK) — uma característica de CPU que permite proteger regiões de memória com chaves de hardware — para reduzir a possibilidade de leitura cruzada entre heaps de isolates.

Dados reproduzidos do estudo: os experimentos foram realizados em servidores Linux com processadores AMD EPYC Zen 2 e Zen 3; para obter a taxa máxima de exfiltração os autores trabalharam em janelas de baixa carga (10–25% CPU noturna), e relataram uma precisão de 99.16% na recuperação de bits à máxima taxa. Os autores esclarecem que com maior carga de sistema a velocidade diminui, mas a técnica continua sendo viável ainda mais lenta. Comparação histórica: o ataque remoto prévio contra Workers, publicado em 2021 pela Cloudflare e TU Graz, alcançou 120 bits por hora (~2 bits/minuto); a nova medição representa uma melhoria significativa em taxa (até umas 360 vezes mais rápida em condições controladas).

O que significa isso para usuários de Workers e serviços na nuvem: em termos práticos, a técnica demonstra que sob certas condições um ator com código legítimo implantado na mesma plataforma pode —teóricamente — extrair segredos alojados em memória de outros tenants. No teste, um JWT foi filtrado, um tipo de segredo que pode permitir acesso API ou validações de sessão se não estiver acotado em tempo. Embora a capacidade de exfiltrar dezenas de bits por segundo ainda implique um processo relativamente lento para obter segredos longos, a automação e repetição permitem reconstruir chaves ou tokens com o tempo.

O que está confirmado e o que ainda está incerto: está confirmado que a técnica funciona em laboratório contra a configuração de produção anterior ao adesivo, e que a Cloudflare tem implantado mitigações. Não está confirmado que ocorreu exploração em clientes reais; Cloudflare relata não encontrar indicadores nos últimos três anos. É incerto até que ponto as mitigações (combinação de DyPrIs melhorada, V8 Sandbox e MPK) eliminam toda a exploração prática em todos os cenários e arquiteturas, e quanto impacto de desempenho ou compatibilidade terão à escala.

Consequências reais possíveis: para cargas que mantenham Workers longos em memória (por exemplo, Durable Objects com invocações prolongadas) ou que usem WebSockets intensivos, existe um risco maior de co-localização explorável. Segredos de longa duração guardados em memória de Workers (chaves API, JWT com TTL amplas, credenciais em variáveis globais) são os ativos mais vulneráveis. Para ambientes multi-tenant onde a co-localização é comum, este tipo de canal sublinha a tensão entre otimização de latência e isolamento purista por processo.

Recomendações concretas para desenvolvedores e administradores: em primeiro lugar, trate os segredos como de curta duração: reduzir TTL de tokens, rote chaves críticas com frequência e aplique limits de scope. Evite manter segredos sensíveis em variáveis globais em Workers; use bindings de segredos gerenciados e serviços externos com verificações adicionais (por exemplo, OAuth com refresh controlado). Para arquiteturas que usam Durable Objects ou conexões WebSocket, considere acotar o tempo de vida de invocações longas ou fragmentar estado para minimizar superfícies em memória. Active e reveja as políticas e logs do seu fornecedor para detectar co-localizações incomuns ou padrões de WebSocket longos. Se você lidar com dados muito sensíveis, avalie exigir execução em ambientes com isolamento por processo ou instâncias dedicadas.

Recomendações para operadores de plataformas: implemente detecção em tempo real durante a execução (não apenas pós-invogação), e utilize sinais que não possam ser facilmente atenuados por atividade de I/O. Combinar proteções de hardware como MPK com sandboxing de V8 e layouts de memória rotativos reduz a probabilidade de que duas isolates compartilhem a mesma chave de proteção, mas essas medidas devem ser avaliadas diante de cargas reais e em múltiplas arquiteturas de CPU. Mantenha auditorias e buscas proativas de padrões de temporização remota que usem WebSockets como canal e limite a exposição de conexões persistentes quando não forem necessárias.

Fontes e leitura adicional: explicação técnica original de Spectre https://spectreattack.com/spectre.pdf, e a documentação do Cloudflare Workers para entender o modelo operacional de isolates e Durable Objects https://developers.cloudflare.com/workers/. Para detalhes sobre Memory Protection Keys em CPU x86, consulte o guia Intel sobre MPK https://www.intel.com/content/www/us/en/developer/articles/technical/memory-protection-keys.html.

Em resumo: a pesquisa reabre a discussão sobre a segurança de oferecer isolamento a nível de linguagem (V8 isolates) dentro de um mesmo processo para otimizar latência. As atenuações por Cloudflare reduzem a superfície de ataque, mas a responsabilidade partilhada recai também em desenvolvedores e operadores: minimizar tempos de vida de segredos, evitar padrões de execução longos em memória e auditar uso intensivo de WebSockets são passos práticos que limitam a exposição enquanto se continua a avaliar a eficácia das proteções em escala.