HTTP/2 Bomb: a vulnerabilidade que pode esvaziar a RAM dos seus servidores em segundos

Um novo método de recusa de serviço batizado por seus descubridores como HTTP/2 Bomb demonstra que a combinação de técnicas já conhecidas pode voltar vulneráveis a servidores modernos em questão de segundos: HPACK (a compressão de cabeçalhos de HTTP/2) é usada para amplificar o uso de memória e o controle de fluxo de HTTP/2 é manipulada para reter indefinidamente essa memória atribuída.

Segundo o relatório técnico publicado pelos pesquisadores de Calif, e disponível em seu blog, uma única máquina doméstica com uma conexão de 100 Mbps pode forçar servidores como Envoy, Apache httpd, NGINX ou IIS a consumir dezenas de gigabytes de RAM em segundos; os experimentos reproduzidos pela equipe mostram rácios de amplificação extremos - até 5700 bytes consumidos por cada byte enviado no caso de Envoy - e esgotamentos de 32–64 GB em menos de um minuto em configurações por defeito. Mais detalhes e contexto da descoberta estão no comunicado de Calif: https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb.

A primeira "pata" do ataque explora como o HPACK mantém uma tabela dinâmica de entradas de cabeçalho: o atacante insere uma pequena entrada e a referência de forma repetida usando sua representação indexada de um byte, conseguindo que uma quantidade mínima de dados de rede provoque grande quantidade de memória interna pela contabilidade e estruturas que o servidor reserva para cada cabeçalho. A segunda “pata” aproveita o mecanismo de controle de fluxo de HTTP/2: o cliente anuncia uma janela de zero bytes e evita que a resposta seja completa, enquanto o servidor envia rajadas pequenas de WINDOW_UPDATE ou mantém o estado da conexão para evitar tempo de espera; o resultado é que a memória reservada não é liberada.

Essa abordagem evade medidas tradicionais que limitam o tamanho total de cabeçalhos descodificados porque os cabeçalhos usados na exploração são intencionalmente pequenas; a amplificação ocorre na gestão interna por cabeçalho e em estruturas relacionadas ao estado de fluxo. A especificação do HPACK reconhece riscos de amplificação de memória, mas os pesquisadores apontam que não aborda adequadamente o efeito combinado com a retenção indefinida via controle de fluxo: a interação entre subsistemas é o que provoca o impacto catastrófico.

Calif publicou já provas de conceito no GitHub, pelo que operadores e equipamentos de segurança devem agir com prudência e premura: https://github.com/califio/publications/tree/main/MADBugs/http2-bomb. Também é recomendável repassar a especificação de HPACK para entender a raiz do problema técnico: https://httpwg.org/specs/rfc7541.html.

Alguns fornecedores e projetos já lançaram mitigações: NGINX introduziu a directiva max_ headers Na versão 1.29.8 e Apache corrigiu mod_http2 na versão assinalada pela equipe; no entanto, a data deste relatório não existiam adesivos oficiais para todas as implementações afetadas, incluindo certas versões de Envoy, Microsoft IIS ou o motor Pingora de Cloudflare. Onde não houver adesivo disponível, as recomendações pragmáticas são desactivar o HTTP/2 se for viável, ou colocar um proxy inverso/CDN que filtre e limite o número de cabeçalhos e controles de fluxo antes que cheguem ao servidor de origem.

Para equipas de operações e resposta a incidentes, as acções específicas que devem ser prioritárias incluem a aplicação de sistemas de correcção disponíveis imediatamente, a revisão da exposição de endpoints HTTP/2 em infra-estruturas públicas, a disponibilização de limites rigorosos por ligação (número máximo de cabeçalhos e streams simultâneos), e a garantia de que os proxies ou o WAFs aplicam limiares duros. Além disso, estabelecer limites de recursos por processo/worker e regras do kernel (OOM-killer e cgroups) ajuda a conter o dano quando a memória começa a crescer.

Quanto à detecção, os indicadores precoces são padrões invulgares de streams em estado "half-open" ou com janelas de fluxo persistentes em zero, um aumento rápido no uso de memória por processos HTTP/2, e um número elevado de entradas repetidas nos contadores de cabeçalhos descodificados. Monitorizar métricas de ligação, tempos de resposta e contadores internos do módulo HTTP/2 de cada servidor facilita a identificação de tentativas de exploração antes da máquina inutilizável.

Esse achado também tem uma dimensão relevante para a comunidade: foi descoberto com ajuda de um agente de software (Codex) coordenado por pesquisadores humanos, o que destaca como ferramentas de IA podem acelerar a identificação de vetores complexos, mas também como seu uso requer normas de divulgação responsável. A apresentação técnica completa será pública na conferência Real World AI Security; entretanto, a existência de PoC obriga a agir como se o risco fosse real e explorável.

Se o seu serviço for servido por tráfego público, prioriza um inventário rápido de quais componentes expõem HTTP/2, atualiza a NGINX/Apache quando apropriado e, se você não puder corrigir imediatamente, coloca um CDN/proxy que faça a validação e limite conteos de cabeçalhos por conexão. Documenta as medidas e testes de mitigação em seu playbook de incidentes: a rapidez de detecção e a aplicação de limites por conexão são a diferença entre um incidente menor e uma queda completa do serviço.

Por último, a natureza do problema lembra que a segurança de protocolos modernos não depende apenas de especificações individuais, mas de suas interações em implementações reais; as equipes responsáveis por infra-estruturas devem incorporar testes de estresse específicos para HTTP/2 em suas validações de segurança e arquitetura defensiva.