Cloudflare corrige falhas em Containers que permitia ler dados residuais em discos compartilhados

O Cloudflare corrigiu uma vulnerabilidade no seu serviço de Containers que permitiu a um cliente autorizado ler dados residuais deixados por contêineres de outros clientes em discos compartilhados, conforme comunicaram a empresa e os pesquisadores que informaram a falha. O problema não implicou acesso a processos em execução de outros clientes, nem a capacidade de escolher quem pertencia a informação recuperada, mas deixou blocos de armazenamento com restos de arquivos — directorios, páginas de bases de dados e bases SQLite completas, segundo a contagem — que um atacante com acesso ao recipiente pôde extrair.

Atos confirmados: o pesquisador Oren Yomtov, da assinatura Accomplish, relatou a falha da Cloudflare em 4 de setembro; a causa técnica foi a reconfiguração de discos em modo "thin provisioning" (capacidade granular de alocação em blocos de 64 KB) de modo que, ao devolver blocos ao pool compartilhado, o sistema não os limpava antes de reasignar; Cloudflare reactivou a remoção de novos blocos e retirou/reciclaron as unidades em produção, completando a limpeza em 19 de setembro e divulgando o incidente cinco dias depois. Os pesquisadores verificaram o adesivo em 14 de setembro e confirmaram que seu teste de conceito deixou de funcionar.

Como funcionou tecnicamente (explicação): os discos atribuídos a contentores são criados por um dispositivo de tipo thin provision, que atribui espaço em blocos de 64 KB. Quando um recipiente é destruído, seus blocos voltaram ao pool geral. Devido a uma configuração que omitia a limpeza (wipe/zero) ao reasignar blocos, o próximo recipiente que recebe esse bloco podia escrever apenas 4 KB dentro dos 64 KB e depois ler o bloco em nível bruto; o restante dos 60 KB permanecia com os bytes do inquilino anterior. Os pesquisadores exploraram exatamente isso: escreveram um fragmento pequeno e leu o bloco inteiro desde o nível de bloco cru para recuperar dados residuais. Esse vetor ataca a reutilização não segura de blocos, não a memória a quente nem a integridade de processos em execução.

Quais sistemas e clientes foram afetados: Cloudflare Containers e o seu produto Cloudflare Sandboxes(uma camada pensada para executar código não confiável, incluindo agentes de IA) foram identificados como afetados. Os pesquisadores também apontaram que a mesma configuração de disco afetava o produto Browser Run, embora Cloudflare só nomeou Containers e Sandboxes em seu comunicado. O Cloudflare controla a atribuição física de servidores e discos, de modo que a exposição veio do lado do fornecedor e não de uma escolha do cliente.

Alcance observado pelos pesquisadores e pela Cloudflare: em testes de produção controlados, os pesquisadores recuperaram material residual em 18 de 24 tentativas em servidores escolhidos pela Cloudflare, e em 20 de 22 máquinas físicas repartidas em quatro continentes; os restos incluíam listas de diretórios, perfis de navegador (Chromium), arquivos .env, arquivos de credenciais e bases SQLite, segundo o relatório dos pesquisadores e a confirmação parcial de Cloudflare. Cloudflare diz que suas indagações internas —basadas em assinaturas criadas a partir do teste de conceito — só encontraram atividade autorizada (a dos pesquisadores e seu próprio pessoal) nos registros conservados.

O que está confirmado e o que ainda está incerto: é confirmado que houve exposição de dados residuais em blocos de disco resignados e que a Cloudflare aplicou duas remediações (reactivar a remoção ao atribuir novos blocos e substituir/desplegar discos e caches em produção). É uma estimativa razoável — embora não matematicamente comprovada publicamente — que os restos poderiam conter segredos úteis (tokens, chaves, credenciais) dado que apareceram .env e bases de dados. O incerto é a janela total de exposição: Cloudflare não especificou desde quando esteve ativa a configuração insegura ou por quanto tempo em termos absolutos, de modo que não se pode quantificar com certeza quantos clientes estiveram potencialmente expostos ou durante que período exato.

Riscos reais para clientes e consequências práticas: a informação recuperada pode incluir credenciais, tokens API, segredos de configuração ou porções de bases de dados que permitem ataques posteriores (reutilização de credenciais, escalada fora do ambiente, acesso a serviços conectados). Embora não haja evidência pública de abuso por terceiros, a combinação de dados parciais recuperados e mecanismos automatizados de análise pode facilitar a reconstrução de segredos. Além disso, para organizações sujeitas a requisitos regulatórios ou de cumprimento, a mera possibilidade de exfiltração de dados em um ambiente multi-tenant pode requerer notificações ou revisões internas.

Medidas concretas a tomar pelos clientes afetados ou em risco: em primeiro lugar, identifique se usa Containers, Sandboxes ou Browser Run e quais imagens ou contentores puderam conter segredos em disco ou em camadas de imagem. A seguir, rote imediatamente qualquer credencial que pudesse ter estado nesses contentores: tokens de API, chaves de bases de dados, segredos em arquivos .env e chaves SSH. Não espere apenas à confirmação do fornecedor; a rotação proativa é uma ação de baixo custo frente ao risco. Revocar tokens e regenerar credenciais nos serviços conectados (bancos de dados, serviços cloud, APIs de terceiros) é a medida mais direta para mitigar um possível uso indevido.

Outras acções técnicas recomendadas: deixe de armazenar segredos no sistema de ficheiros persistente de contentores; use serviços de secret management (vaults) ou mecanismos de gestão de segredos que injetem valores em tempo de execução sem os escrever em disco; monte segredos em memória (tmpfs) quando viável; cifre os dados sensíveis a nível de aplicação antes de os escrever a disco para que a exposição de blocos não permita ler chaves claras. Ver boas práticas em gestão de segredos: OWASP Secrets Management Cheat Sheet.

Verificação e monitoramento: verifique logs e atividade incomum nos serviços que usam os contentores afetados; procure acessos a partir de IPs ou padrões inesperados e configure alertas sobre uso anormais de chaves. Embora a Cloudflare tenha informado ter executado detecção baseada em assinaturas, convém aplicar detecção própria de anomalias em serviços críticos e auditar imagens e camadas de contêineres em busca de segredos embebidos.

Contexto técnico adicional e referências: este problema é um exemplo de como as optimizações de performance e a configuração a baixo nível do armazenamento (thin provisioning e caching de camadas) podem introduzir vetores de fuga de dados em ambientes multitenant. Para entender o mecanismo de thin provisioning e seus riscos técnicos, você pode consultar a documentação do kernel do Linux sobre Device Mapper Thin Provisioning: kernel.org — Thin provisioning. Para instruções práticas sobre como gerenciar segredos em contentores e reduzir este tipo de riscos, a documentação de boas práticas de plataformas e orquestradores é útil (por exemplo, práticas de Docker e Kubernetes e gestão de segredos).

Conclusão: Cloudflare fechou a via de ataque detectada e limpou os recursos em produção, e não há agora indícios públicos de abuso maciço. No entanto, a natureza da falha – leitura de dados residuais em discos compartilhados – implica que qualquer cliente que tenha guardado segredos em imagens ou discos de contentor deve rodar credenciais e rever práticas de gestão de segredos. A lição operacional é clara: em ambientes multitenant, a defesa deve incluir tanto controles do fornecedor quanto práticas rigorosas dos desenvolvedores para não deixar segredos em disco nem confiar exclusivamente na segurança física ou do hipervisor.

Fontes e leitura adicional: o comunicado e seguimento do fornecedor estão disponíveis no blog Cloudflare https://blog.cloudflare.com/, e a explicação técnica de thin provisioning no Linux pode ser consultada na documentação oficial do kernel: https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/thin-provisioning.html.