HTTP/3 e QPACK: limite o conteúdo expandido, não só o pacote recebido

A FoxIO relatou falhas de negação de serviço na descompressão QPACK do HTTP/3 em sete das dez pilhas testadas.[8] O problema permite que uma representação pequena de cabeçalhos gere um conjunto muito maior em memória quando os limites consideram só a entrada comprimida ou chegam depois da expansão.[8]

O que muda para quem desenvolve

A unidade de controle importa. Minha análise: contar bytes de rede não é suficiente para limitar o trabalho que uma requisição exige do servidor. A proteção precisa acompanhar tanto a expansão quanto o total retido ao longo do processamento.

No Bun, o estudo descreve uma verificação por cabeçalho que não limitava o conjunto acumulado; o experimento chegou a conteúdo expandido superior a 2 GB com aproximadamente 516 KB transmitidos.[8] O HTTP/3 do Bun é identificado como experimental, e na divulgação ainda não havia correção correspondente para ele, h3 do ecossistema Rust e aioquic/mitmproxy.[8]

As versões corrigidas citadas são quic-go 0.57.0, Cloudflare quiche 0.29.3, lsquic 4.9.0 e Wireshark 4.6.2 ou 4.4.12.[8] É necessário descobrir onde o protocolo termina, pois a atualização pode pertencer ao proxy ou ao túnel, não à aplicação.

Como aplicar

Desenhe o caminho da conexão: cliente, CDN, proxy, túnel e servidor. Para cada ponto que negocia HTTP/3, registre produto, biblioteca incorporada e evidência da versão corrigida. Não confunda a implementação quiche da Cloudflare com a do Google, que a reportagem lista como não afetada.[8]

Em laboratório isolado, proponho medir memória e tempo de processamento sob variação controlada do número de cabeçalhos e do tamanho expandido. Defina limites pequenos, encerramento automático e nenhuma rota para produção. O objetivo é confirmar rejeição previsível e recuperação, não descobrir quanta memória uma máquina consegue perder.

Para componentes sem remendo, avalie desabilitar temporariamente HTTP/3 e teste o caminho alternativo antes da mudança. A fonte cita medidas específicas, como não expor o servidor experimental do Bun e desabilitar HTTP/3 no mitmproxy.[8]

Cuidados e limites

O estudo não apontou roubo de dados, execução de código ou ataques conhecidos em circulação.[8] Não amplie o impacto além da disponibilidade demonstrada.

O caso do Wireshark ocorre ao analisar tráfego HTTP/3 descriptografado com segredos presentes na captura, e não por atender uma conexão pública como servidor.[8] Atualizar ferramentas de análise continua importante, mas o cenário é outro. Comprar mais memória não substitui impor limites enquanto os dados são expandidos.

Fonte

[8] Fonte: The Hacker News