Inundação de `CONTINUATION` no HTTP/2: detalhes técnicos

Vulnerabilidade de Flood de CONTINUATION no HTTP/2: detalhes técnicos

• O Flood de CONTINUATION é uma categoria de vulnerabilidades encontrada em várias implementações do protocolo HTTP/2, representando uma ameaça ainda mais grave do que o ataque Rapid Reset.
• Os impactos do ataque variam de falhas no servidor a degradação de desempenho, e as requisições maliciosas não aparecem nos logs de acesso HTTP.

Introdução

• Em outubro de 2023, tomou-se conhecimento do ataque HTTP/2 Rapid Reset, e decidiu-se iniciar uma pesquisa sob a perspectiva de análise de segurança do HTTP/2.

Breve introdução ao HTTP/2

• A principal diferença entre HTTP/1.1 e HTTP/2 é que o segundo é um protocolo binário, no qual cliente e servidor trocam frames em vez de linhas de texto.
• É necessário explicar os frames HEADERS e CONTINUATION.

Frame HEADERS

• O frame HEADERS é usado para transmitir os cabeçalhos HTTP de requisições e respostas, comprimindo os dados dos cabeçalhos com o algoritmo de codificação HPACK.
• No frame, podem ser definidos flags como END_HEADERS e END_STREAM.

Frame CONTINUATION

• O frame CONTINUATION é muito semelhante ao frame HEADERS, mas possui apenas o flag END_HEADERS; quando esse flag é definido, isso significa que o fluxo de cabeçalhos terminou.

Vulnerabilidade de Flood de CONTINUATION

• Quando um cliente inicia um novo stream HTTP/2 e envia frames HEADERS e CONTINUATION, mas o flag END_HEADERS nunca é definido, o servidor precisa analisar e armazenar em memória um fluxo de cabeçalhos infinito.
• No HTTP/1.1, há proteção contra cabeçalhos infinitos por meio de limites de tamanho de cabeçalho e timeouts de requisição/cabeçalho, mas em muitos servidores HTTP/2 essas proteções estão ausentes ou foram implementadas incorretamente.

Consumo de CPU: caso do Golang

• O Golang é um exemplo de consumo de CPU causado por Flood de CONTINUATION, usando uma classe abstrata chamada http2MetaHeadersFrame para processar os frames HEADERS e CONTINUATION.
• O decodificador HPACK é configurado para interromper a emissão de cabeçalhos ao atingir o limite de tamanho de cabeçalho, mas sem o flag END_HEADERS a função não retorna e continua decodificando cabeçalhos.

Falta de memória

• A falta de memória é um dos casos mais graves, pois existem implementações que não limitam o tamanho da lista de cabeçalhos construída com frames CONTINUATION.
• Em implementações sem timeout de cabeçalho, é possível derrubar o servidor com apenas uma única conexão HTTP/2.

Colisão por assertion alcançável: Node.js (caso especial)

• O Node.js lida corretamente com um fluxo infinito de frames CONTINUATION, mas ocorre um bug de race condition quando a conexão é encerrada durante o fluxo de cabeçalhos.
• O Node.js rastreia a alocação de memória dentro do destrutor de Http2Session, e quando a conexão é encerrada, o valor current_nghttp2_memory_ pode ser atualizado simultaneamente, causando uma falha.

Comparação com vulnerabilidades anteriores do HTTP/2

• No passado, várias vulnerabilidades de HTTP/2 já foram relatadas, e o Flood de CONTINUATION opera de forma diferente das vulnerabilidades anteriores.
• Em vez de enviar cabeçalhos vazios, o Flood de CONTINUATION envia muitos cabeçalhos arbitrários até o limite de tamanho de frame definido pelo servidor.

Observações finais

• O tráfego HTTP/2 representa cerca de 60% de todo o tráfego HTTP humano e, considerando a importância dos projetos afetados, uma parte significativa da internet foi impactada por uma vulnerabilidade facilmente explorável.
• Se essa vulnerabilidade tivesse sido explorada em ambiente real, teria sido extremamente difícil para administradores de servidor depurá-la sem conhecimento adequado de HTTP/2.

Opinião do GN⁺

• Essa vulnerabilidade pode comprometer seriamente a disponibilidade do servidor e, especialmente por não ser registrada em logs, dificulta o rastreamento e a resposta.
• Administradores de servidor devem aplicar atualizações de segurança regularmente e usar ferramentas de análise de tráfego para detectar padrões anormais.
• Vulnerabilidades como essa servem de alerta para a comunidade de cibersegurança e reforçam a importância de um design e de implementações de protocolo mais seguros.
• Sob uma perspectiva crítica, essa vulnerabilidade revela falhas fundamentais de projeto em um protocolo amplamente usado, levantando questões sobre a confiabilidade da infraestrutura básica da internet.
• Para quem não é especialista com conhecimento na área, pode ser difícil entender e responder a vulnerabilidades complexas como esta, o que torna necessário ampliar a educação e a conscientização em segurança.

[GN⁺]

Comentários no Hacker News

• Esse problema foi corrigido recentemente no Bandit

  • Experiência pessoal de que o mesmo problema foi resolvido no Bandit há um mês.
  • Fornece a localização exata do código por meio de um link.
  • Do ponto de vista de quem implementa, esse problema parecia muito óbvio, e ele achava que outras implementações também já teriam adotado defesas.
  • Porém, ao verificar dezenas de implementações, descobriu que até mesmo servidores HTTP/2 importantes não tinham essas proteções ou as haviam implementado incorretamente.

• Crítica à cultura de desenvolvimento

  • Aponta como problema o fato de os desenvolvedores estarem acostumados demais com coisas que escalam dinamicamente de forma automática, sem pensar no quanto algo pode crescer.
  • Esse tipo de problema não se limita ao HTTP/2, mas a complexidade do HTTP/2 pode agravá-lo ainda mais.
  • No passado, na época do HTTP/1.x, usavam-se linguagens como C e era necessário manter atenção constante ao gerenciamento do tamanho dos buffers; não existia expandir indefinidamente a alocação de cabeçalhos de requisição.

• Lista de servidores/proxies reversos não afetados

  • Lista de servidores web e proxies reversos não afetados mencionados no artigo anterior.
  • Nginx, Jetty, HAProxy, NetScaler e Varnish não são afetados.

• Reflexão sobre a segurança do HTTP/1.1

  • Menciona que o site deles recebeu atenção o dia todo.
  • Levanta a dúvida se, no caso de um site com pouco tráfego, usar HTTP/1.1 seria mais seguro.

• Elogio ao autor

  • Elogio ao autor por abordar o tema com uma visão ampla, relatar de forma responsável o que encontrou e compartilhar isso de um jeito fácil de ler.

• Menção ao Slowloris v2

  • Brinca que, se esse problema for causado lentamente, poderia ser chamado de 'slowloris v2'.

• Menção a um erro de digitação

  • Acha engraçado o erro de digitação 'serveral retries'.

• Visão crítica sobre o HTTP/2

  • Crítica a como o HTTP/2 pode ser empurrado para um protocolo de camada de aplicação como se fosse uma camada de transporte para "upgrade".