A Cloudflare corrigiu uma vulnerabilidade em Containers e Sandboxes que permitia a um cliente recuperar fragmentos deixados em blocos de disco usados anteriormente por outros clientes. O problema não estava em uma API que esqueceu de verificar um usuário. Nasceu de uma opção de desempenho na camada de armazenamento e de uma diferença entre o tamanho da escrita feita pelo container e o tamanho do bloco físico alocado por baixo.
A empresa afirma que a falha foi completamente corrigida, não exige mudança de configuração dos clientes e não encontrou evidência de exploração maliciosa na telemetria histórica disponível. Pesquisadores conseguiram reproduzir a exposição em produção de forma controlada, o que torna o caso útil para entender por que isolamento multi-tenant precisa continuar válido até nas camadas que uma aplicação normalmente não enxerga.
Um disco virtual sobre um pool compartilhado
Cada Cloudflare Container roda dentro de uma máquina virtual com Firecracker e recebe um disco raiz gravável. Por baixo, a plataforma usava o dm-thin, recurso do Linux para thin provisioning. Em vez de reservar antecipadamente todo o espaço anunciado para o disco virtual, o sistema entrega blocos físicos conforme a aplicação escreve.
Os pools afetados trabalhavam com blocos de 64 KiB. Quando um volume era apagado, seus blocos voltavam para um conjunto que atendia workloads de várias contas. Reutilizar blocos é normal em armazenamento compartilhado; a fronteira de segurança depende de impedir que o novo dono veja os bytes deixados pelo anterior.
A opção que pulava a limpeza
A configuração incluía skip_block_zeroing. Como o nome sugere, ela evitava preencher com zeros um bloco físico recém-alocado antes de entregá-lo ao volume. Uma escrita que cobrisse os 64 KiB substituiria o conteúdo antigo por completo. O problema aparecia quando a nova escrita ocupava apenas uma parte do bloco.
A prova de conceito escrevia 4 KiB em uma região alinhada de 64 KiB ainda não mapeada. O dm-thin entregava um bloco físico reutilizado, sobrescrevia os 4 KiB iniciais e mantinha os 60 KiB restantes como estavam. Uma leitura posterior do dispositivo bruto podia encontrar bytes que aquele container nunca havia gravado.
bloco físico: 64 KiB
escrita nova: 4 KiB
restante: 60 KiB potencialmente não limposLer uma região completamente não mapeada não bastava, porque nesse caso o sistema devolvia zeros sem alocar um bloco. A técnica precisava provocar uma escrita pequena para receber armazenamento real do pool e então examinar a área que não havia sido sobrescrita.
O que os pesquisadores conseguiram observar
O pesquisador Oren Yomtov, da Accomplish, reportou a falha pelo programa de bug bounty em 4 de setembro. A equipe usou checksums de estruturas do ext4 para separar blocos do próprio ambiente de teste de materiais pertencentes a outros filesystems.
Segundo o relatório da Cloudflare, material residual apareceu em 18 de 24 placements e em 20 de 22 nós subjacentes testados, distribuídos por quatro continentes. Os formatos encontrados incluíam estruturas de diretório, páginas de banco de dados e bancos SQLite estruturalmente completos. Os pesquisadores enviaram contagens, offsets e hashes truncados, sem entregar à Cloudflare conteúdos recuperados ou identificadores de terceiros, e confirmaram a exclusão segura dos dados obtidos no teste.
Um atacante não conseguia escolher uma vítima, um host ou um workload específico, nem alterar um disco ativo de outro cliente. A exposição dependia do posicionamento feito pela plataforma e dos blocos que o pool decidisse reutilizar. Essa falta de precisão reduz a capacidade de direcionar o ataque, mas não elimina a quebra de isolamento: bytes de uma conta podiam atravessar para outra.
Por que tirar a opção não resolveu tudo imediatamente
A primeira correção removeu skip_block_zeroing, restaurando a limpeza de novas alocações antes que fossem expostas a um container. Os pesquisadores confirmaram que a técnica original deixou de funcionar. Ainda restavam, porém, blocos já mapeados em discos em execução e snapshots preparados para camadas de imagens OCI.
Esses blocos não passariam novamente pelo caminho de uma nova alocação e, portanto, não seriam limpos apenas com a mudança de configuração. A Cloudflare também precisou aposentar discos em execução, drenar hosts, reiniciar máquinas virtuais e limpar caches de imagens para recriar os mapeamentos com blocos zerados.
“Sem evidência” tem um limite importante
A investigação procurou na telemetria um padrão característico: escritas de 4 KiB seguidas por leituras maiores nas mesmas regiões. A empresa diz que as atividades atribuíveis à técnica vieram dos pesquisadores e dos próprios engenheiros durante a validação.
Isso sustenta a afirmação de que não foi encontrada exploração maliciosa, mas não equivale a uma prova matemática de que nunca houve acesso. Logs têm retenção, granularidade e pontos cegos. A formulação correta é justamente a usada no comunicado: não há evidência dentro dos dados históricos disponíveis.
O aprendizado vai além da Cloudflare
Uma opção de desempenho pode carregar uma hipótese de segurança escondida. Pular o zeroing é seguro quando todos os bytes serão sobrescritos antes da leitura ou quando o bloco nunca cruza uma fronteira de confiança. Num pool multi-tenant com escritas parciais, essa hipótese deixa de valer.
O caso também mostra que virtualização forte não encerra a análise. Firecracker isolava as máquinas virtuais, mas o armazenamento abaixo delas ainda reutilizava recursos. Segurança multi-tenant precisa acompanhar rede, memória, caches, snapshots, aceleradores e discos, incluindo o que acontece quando um recurso deixa um cliente e volta ao pool.
Clientes de Containers e Sandboxes não precisam aplicar uma correção. Para quem projeta plataformas, o alerta é mais duradouro: qualquer otimização que evita limpar ou reinicializar um recurso compartilhado deve demonstrar que uma escrita parcial, um cache antigo ou um caminho de leitura de baixo nível não consegue revelar o ocupante anterior.
