A Cloudflare divulgou os resultados de uma reavaliação de ataques Spectre remotos contra a plataforma Cloudflare Workers, realizada ao longo de 2024 e no início de 2025. A equipe de pesquisa conseguiu construir uma prova de conceito funcional em ambiente de produção e vazar dados de um Worker vítima para um Worker atacante sob controle dos pesquisadores a uma taxa de até 12 bits por segundo e com precisão superior a 99%.
A empresa confirma que o ataque apresentado foi tratado no sistema de produção por meio de medidas adotadas pela equipe do Cloudflare Workers Runtime e que não encontrou indícios de exploração ativa nos três anos anteriores. Os resultados foram publicados em um artigo coautorado por Albert Pedersen, Haocheng Xiao, Sam Ainsworth, Nigel Topham e Martin Schwarzl.
Por que esta pesquisa é importante?
O Workers depende da execução de JavaScript não confiável na borda, na qual dezenas de milhares de locatários podem compartilhar um único processo do sistema operacional por meio de isolamentos do V8. Cada Worker possui um heap de JavaScript separado, o que melhora o tempo de inicialização e a eficiência da hospedagem de um grande número de locatários, mas também significa que uma vulnerabilidade de leitura arbitrária intraprocesso poderia abrir caminho para o vazamento de dados entre locatários.
Os ataques Spectre exploram a execução especulativa nos processadores. Quando o processador prevê o resultado de um ramo de software e executa instruções antes de confirmá-lo, os resultados podem ser posteriormente cancelados, mas efeitos sutis permanecem no estado microarquitetural do processador, incluindo o cache. O atacante pode explorar diferenças no tempo de acesso à memória para inferir bits de dados que não deveria conseguir ler.
A Cloudflare havia lançado em 2021 uma defesa de produção chamada Dynamic Process Isolation, ou DyPrIs, para isolar scripts que parecessem maliciosos em processos separados. No entanto, a reavaliação descobriu uma limitação no mecanismo de execução que permitiu que o ataque permanecesse eficaz por tempo suficiente para contornar o isolamento.
Como o ataque superou as limitações do Workers?
A plataforma restringe temporizadores locais e não permite memória compartilhada nem multithreading; por isso, os métodos tradicionais de medição baseados em SharedArrayBuffer não estavam disponíveis. Em vez disso, os pesquisadores usaram um temporizador remoto por meio de uma conexão WebSocket e aproveitaram a amplificação do sinal resultante de eventos de cache usando a política de substituição tree-based PLRU no cache L1.
A equipe também projetou dois tipos de Spectre gadgets. O primeiro foi usado para vazar ponteiros compactados do heap, incluindo o endereço-base do heap específico do isolamento. O segundo baseou-se na confusão especulativa de tipos para acessar um ponteiro bruto de 64 bits, o que permitiu transformar o vazamento em uma leitura a partir de um endereço escolhido pelo atacante. No momento da pesquisa, o V8 Sandbox ainda não havia sido implementado no Workers, e TypedArray estava entre os casos que mantinham um ponteiro bruto para seu armazenamento subjacente.
Para garantir medições reproduzíveis, os pesquisadores criaram grandes conjuntos de objetos que excediam a capacidade do cache e, em seguida, escolheram locais aleatórios a cada rodada, em vez de procurar um conjunto de despejo preciso para cada linha de memória. Durable Objects também foram usados para manter um contexto de execução de longa duração, enquanto as mensagens WebSocket permitiram redefinir os limites de tempo de processamento e de solicitações. Com o uso de pausas periódicas entre lotes de execução, foi possível manter o isolamento ativo de cinco horas a mais de 20 horas.
Para obter proximidade entre atacante e vítima, o Worker atacante chamou o Worker vítima por meio de fetch, o que, na maioria dos casos, fez com que ambos fossem executados no mesmo processo do mesmo servidor de borda. Essa abordagem também permitiu aproveitar períodos de baixa carga nos centros de borda para aumentar a estabilidade das medições.
O que mudou, na prática, nas defesas da Cloudflare?
A Cloudflare introduziu várias modificações, em vez de depender de uma única medida. O V8 Sandbox passou a fazer parte das camadas de proteção e tem como objetivo reduzir a presença de ponteiros brutos de 64 bits em grandes partes do heap de JavaScript. Isso torna mais difícil reutilizar algumas das ferramentas de confusão especulativa usadas na pesquisa, mas não constitui uma solução completa contra ataques Spectre, pois outras ferramentas ou formas de acesso fora dos limites da memória podem surgir.
Em setembro de 2025, a empresa lançou um isolamento intraprocesso baseado em Memory Protection Keys, ou MPK. Essa tecnologia divide a memória em domínios de proteção e alterna seus direitos de acesso a baixo custo, de modo que o heap de cada isolamento fique atrás de uma barreira imposta pelo hardware. Isso impede a leitura direta entre os heaps dos isolamentos explorada pelo ataque, mas não elimina todos os riscos de Spectre; o número de domínios de proteção é limitado, e o sistema também exige um gerenciamento cuidadoso do estado das chaves de proteção.
A Cloudflare também aprimorou o mecanismo DyPrIs para lidar com operações de longa duração e cargas intensivas de entrada e saída. Esperar o término da chamada para isolar o script não é suficiente quando uma conexão WebSocket ou um Durable Object pode manter a chamada aberta por horas. A empresa também está estudando a inclusão do comportamento de temporização remota nos sinais de detecção, especialmente quando operações semelhantes a temporizadores são repetidas em torno de partes intensivas em computação, em vez de considerar o tráfego de rede associado um ruído normal.
Limitações do resultado
O teste foi realizado contra Workers controlados pela Cloudflare e pelos pesquisadores, e não constitui prova de comprometimento de locatários reais. Além disso, a maior taxa de vazamento ocorreu às custas da precisão, segundo esclarecimento da empresa, e não foram observados indícios de exploração real nos três anos anteriores. Portanto, os resultados revelam uma capacidade ofensiva executável no modelo de isolamento anterior e a importância de combinar isolamento de processos, proteção de memória imposta pelo hardware e detecção comportamental contínua.