CVE-2023-44487

Rapid Reset é uma falha de design no protocolo HTTP/2 (CWE-400, consumo descontrolado de recursos) que permite negação de serviço explorando a forma como o protocolo trata cancelamento de streams via RST_STREAM. Não é uma falha de um produto específico: afeta praticamente toda implementação de servidor, proxy ou biblioteca HTTP/2 que não limite a taxa de abertura/cancelamento de streams por conexão. A CVE ganhou peso real porque foi usada em ataques DDoS de escala recorde entre agosto e outubro de 2023 contra Cloudflare, Google e AWS, antes mesmo da divulgação pública.

No HTTP/2 multiplexado, um cliente abre um stream enviando um frame HEADERS com a requisição e pode cancelá-lo unilateralmente a qualquer momento enviando RST_STREAM, sem coordenação com o servidor. O protocolo assume que o cancelamento é imediato e não impõe custo ao cliente por isso — mas o servidor, ao receber o HEADERS, já alocou estrutura de stream, fez parsing de headers (com decompressão HPACK), roteou a URL para um recurso e, em topologias de proxy reverso, muitas vezes já encaminhou a requisição ao backend antes de processar o RST_STREAM.

O ataque consiste em abrir um número muito grande de streams em uma única conexão TCP e cancelar cada um imediatamente após enviá-lo, sem esperar resposta. Como o cliente nunca deixa um stream aberto por muito tempo, ele nunca atinge o limite de streams concorrentes (SETTINGS_MAX_CONCURRENT_STREAMS) que normalmente restringe o abuso de HTTP/2. Isso rompe a defesa histórica contra flood de streams: o volume de requisições processadas por conexão deixa de depender do round-trip time e passa a depender só da largura de banda disponível no cliente.

O resultado é uma assimetria de custo brutal: o atacante paga quase nada para enviar HEADERS+RST_STREAM, enquanto o servidor paga o custo completo de alocação, parsing e roteamento para cada requisição cancelada. Em servidores com poucas conexões concorrentes é possível gerar um volume de "requisições por segundo" efetivas muito acima do que a infraestrutura foi dimensionada para tratar, sem nunca completar uma requisição de fato.

O CWE aplicável é CWE-400 (Uncontrolled Resource Consumption). Não há um único ponto de código vulnerável: cada implementação de HTTP/2 (Netty, Tomcat, Jetty, nghttp2, swift-nio-http2, golang.org/x/net, akka-http, H2O, Envoy, HAProxy, gRPC, hyper, entre outras) precisou de correção própria, porque a lacuna está na ausência de limite de taxa para reset de streams por conexão, não em uma implementação incorreta de um RFC.

O vetor é rede pura: qualquer cliente TCP capaz de estabelecer conexões HTTP/2 pode disparar o ataque, sem autenticação, sem interação do usuário e sem pré-condição de configuração no lado do servidor — basta que o serviço aceite HTTP/2. A complexidade de execução é baixa; existem PoCs públicas (por exemplo o gerador de tráfego usado para reproduzir o comportamento, referenciado nos advisories) que abrem e resetam streams em loop.

Na prática documentada, os operadores de CDN e provedores de nuvem relataram exploração massiva entre agosto e outubro de 2023, com picos de requisições por segundo muito acima de qualquer DDoS de camada 7 registrado até então (a Cloudflare descreveu ataques na ordem de centenas de milhões de requisições por segundo usando botnets relativamente modestos em número de máquinas, justamente pela eficiência da técnica). A CISA confirmou exploração ativa no mundo real, o que motivou a inclusão no catálogo KEV.

O resultado final do ataque é indisponibilidade do serviço — esgotamento de threads, conexões de worker, memória ou CPU do servidor/proxy, ou saturação de backend por requisições encaminhadas antes do cancelamento chegar — sem qualquer comprometimento de confidencialidade ou integridade (por isso C:N/I:N no vetor CVSS, com impacto concentrado em A:H).

Não existe um único patch de fornecedor: a correção precisa ser aplicada implementação por implementação, e a lista de versões corrigidas varia por projeto. Entre as citadas nos advisories: golang.org/x/net corrigido em 0.17.0; nghttp2 corrigido em 1.57.0; swift-nio-http2 em 1.28.0; akka-http-core em 10.5.3 (ramos 2.12/2.13) — o ramo 2.11 (<=10.1.15) não recebeu correção; Apache Tomcat em 8.5.94, 9.0.81, 10.1.14 e 11.0.0-M12; Eclipse Jetty em 9.4.53, 10.0.17, 11.0.17 (módulos http2) e 12.0.2 (módulo jetty-http2). Outros projetos afetados incluem Netty, Envoy, HAProxy, gRPC-go, hyper, Node.js, .NET/ASP.NET Core, Caddy, Traffic Server, H2O, proxygen e Tengine, cada um com seu próprio ciclo de release — checar o advisory específico do stack em uso é obrigatório, já que a faixa de versão vulnerável e a corrigida não são as mesmas entre projetos.

Quando atualizar não é viável de imediato, o paliativo real é limitar a taxa de reset de streams por conexão (janela deslizante de RST_STREAM, como implementado no swift-nio-http2 1.28) ou derrubar a conexão de clientes que excedem um número razoável de streams abertos/cancelados por segundo — algumas implementações expõem isso via callback (nghttp2_on_frame_recv_callback, contando RST_STREAM) ou via configuração de limite de conexões HTTP/2 e goaway forçado. Reduzir MAX_CONCURRENT_STREAMS não mitiga o ataque, porque o Rapid Reset especificamente contorna esse limite ao nunca deixar streams simultaneamente abertos. Desabilitar HTTP/2 e forçar HTTP/1.1 remove a exposição por completo, ao custo de multiplexação e performance — é mitigação funcional, mas não é solução, apenas troca de superfície.

O que não funciona: rate limiting apenas por número de conexões TCP ou por requisições HTTP completas não pega o ataque, porque as requisições nunca completam — o controle precisa olhar para frames RST_STREAM e HEADERS dentro da conexão HTTP/2, não para requisições HTTP terminadas nos logs de acesso tradicionais.

O sinal característico é o padrão HEADERS seguido imediatamente de RST_STREAM, repetido em alto volume dentro de uma mesma conexão TCP/HTTP2 — um número de streams abertos-e-cancelados por segundo muito acima do padrão de navegação humana ou de clientes legítimos. Ferramentas com telemetria de frame HTTP/2 (proxies, WAFs com inspeção de protocolo, ou logging customizado de RST_STREAM via callback da biblioteca HTTP/2) conseguem captar isso; logs de acesso HTTP tradicionais não mostram nada de anormal, porque as requisições nunca completam e frequentemente nem aparecem no log de acesso do servidor de aplicação.

Em nível de rede, indicadores indiretos incluem picos de CPU/memória do processo servidor sem aumento correspondente de requisições completadas nos logs, aumento de conexões HTTP/2 de curta duração com contagem de streams por conexão anormalmente alta, e alertas de rate limiting de conexão disparando repetidamente para os mesmos IPs de origem — mas sem visibilidade a nível de frame HTTP/2, a detecção fica limitada a sintomas de esgotamento de recursos, não à causa raiz.