Mat Trudel

Um invasor remoto não autenticado pode esgotar a memória do servidor enviando um corpo de requisição composto por inúmeros frames DATA de 1 byte. O problema ocorre no leitor de corpo de requisição HTTP/2, onde a função `do read data/5` em `lib/bandit/http2/stream.ex` armazena cada payload de frame DATA como um elemento de lista individual até que a operação de leitura retorne. Como a opção `:length` de `read body/2` rastreia o número total de bytes e não o número de frames, um grande volume de frames pequenos cria uma sobrecarga de memória significativa por byte. Esse efeito é amplificado quando os frames são intercalados em até 500 streams simultâneos por conexão. Este problema afeta qualquer rota onde o Plug leia o corpo da requisição, incluindo aquelas que utilizam `Plug.Parsers` para requisições POST, PUT e PATCH.

Um invasor remoto não autenticado pode esgotar a memória do servidor enviando quadros DATA que excedem a janela de recebimento anunciada na implementação HTTP/2. O invasor pode solicitar uma resposta maior que a janela inicial de 65.535 bytes e reter o `WINDOW UPDATE`, fazendo com que o processo de fluxo bloqueie durante o envio e pare de ler. Subsequentemente, a inundação de pequenos quadros DATA nesse fluxo faz com que cada quadro seja enfileirado na caixa de correio do fluxo até que o nó BEAM fique sem memória. Isso ocorre porque a função `Bandit.HTTP2.Connection.handle frame/3` encaminha os quadros DATA para o processo de fluxo sem consultar a janela de recebimento, e a função `Bandit.HTTP2.FlowControl.compute recv window/2` reabastece a janela conforme os dados chegam, em vez de quando são consumidos, não disparando um `FLOW CONTROL ERROR` em caso de violação.

Um problema de complexidade algorítmica ineficiente na implementação do HTTP/2 permite que um invasor remoto não autenticado esgote os recursos de CPU do servidor. Ao abrir milhares de fluxos que bloqueiam na janela de envio da conexão e, subsequentemente, enviar pequenos quadros SETTINGS ou WINDOW UPDATE no nível da conexão, um invasor pode forçar o servidor a realizar operações de lista quadráticas O(n²). Isso ocorre porque a função `do pending sends/2` em `lib/bandit/http2/connection.ex` tenta reenviar cada envio enfileirado e remove entradas usando `List.delete/2`, fazendo com que o servidor percorra toda a fila de envios bloqueados para cada quadro. O impacto é amplificado porque o `max concurrent streams` tem como padrão `:infinity`, permitindo que o invasor controle o número de fluxos bloqueados.

Um invasor remoto não autenticado pode causar o esgotamento da memória do servidor através de um problema de amplificação de dados na implementação do HTTP/2. Ao enviar um bloco HEADERS pequeno comprimido via HPACK que armazena um valor de `cookie` grande na tabela dinâmica HPACK e o referencia milhares de vezes, o invasor pode forçar o servidor a alocar um binário massivo. Isso ocorre porque `Bandit.HTTP2.Connection` limita apenas o tamanho do bloco comprimido através de `max header block size`, enquanto a configuração `max header list size` tem como padrão `:infinity`, não rejeitando a lista expandida. A função `combine cookie crumbs/1` em `lib/bandit/http2/stream.ex` então une essas referências em um único binário grande. Como `max concurrent streams` também tem como padrão `:infinity`, múltiplos fluxos simultâneos podem multiplicar esse consumo de memória, potencialmente derrubando todas as aplicações no nó BEAM.

Um problema no tratamento de conexões WebSocket permite que um cliente remoto continue executando o código do manipulador após o servidor ter tentado interromper a conexão. Isso ocorre porque, quando um callback retorna `{:stop, ...}`, o processo `Bandit.WebSocket.Connection` entra em um estado `:closing`, mas continua a processar frames de dados e mensagens recebidas. As funções `handle frame/3` e `handle info/3` não verificam o estado da conexão, permitindo que frames alcancem `handle in/2` e mensagens alcancem `handle info/2` até que o cliente envie um frame Close, a conexão TCP caia ou ocorra um tempo limite de inatividade. Isso pode levar à evasão de verificações de autorização em `init/1` ou a ignorar o encerramento de sessões, como expulsões ou banimentos, permitindo potencialmente o acesso não autorizado a ações administrativas.

Um invasor remoto não autenticado pode causar o crescimento ilimitado do uso de memória e CPU por conexão na implementação do HTTP/2. Isso ocorre porque o software redimensiona sua tabela de codificação HPACK com base no `SETTINGS HEADER TABLE SIZE` anunciado pelo cliente sem aplicar um limite no servidor, permitindo tamanhos de até 2^32-1 bytes. Como os cabeçalhos de resposta com valores distintos, como `date` ou `content-length`, são indexados e não removidos, a tabela cresce a cada resposta. Consequentemente, a função `lookup by header` na biblioteca HPAX verifica a tabela linearmente, resultando em um custo de CPU de O(N²) para servir N respostas em uma única conexão. O problema está localizado em `Bandit.HTTP2.Connection` (`lib/bandit/http2/connection.ex`), onde `remote settings.header table size` é passado para `HPAX.resize/2`, e a função `encode headers` codifica cada cabeçalho de resposta como `:store`.

Um invasor remoto não autenticado pode esgotar a memória e a CPU do servidor enviando um corpo de requisição composto por inúmeros chunks de 1 byte. O problema reside no leitor de corpo chunked HTTP/1.1 em `lib/bandit/http1/socket.ex`, que mantém cada chunk como sua própria célula de lista e termo binário até que sejam unidos pela função `IO.iodata to binary/1`. Como a opção `:length` da função `read body/2` conta apenas bytes de dados e não limita o número de chunks, chunks minúsculos consomem muito mais memória do que sua carga útil. Isso pode ocorrer mesmo que a rota não precise ler o corpo, pois a função `ensure completed/1` drena corpos não lidos em conexões keep-alive.

Um processo de limpeza inadequado durante exceções lançadas no manipulador HTTP/2 permite que um invasor remoto não autenticado ignore os limites de recursos por conexão. Quando um quadro gera um `StreamError` durante o processamento de um chunk TCP, a função `handle data/3` em `Bandit.HTTP2.Handler` envia um RST STREAM e reverte o estado da conexão para a condição anterior ao processamento do chunk. Embora as streams abertas por quadros anteriores no chunk continuem a executar suas chamadas Plug, a contabilidade interna — incluindo contagens de stream, `last stream id`, timestamps de rapid-reset e o estado do decodificador HPACK — é revertida. Consequentemente, o `max concurrent streams`, `max requests` e o limitador de rapid-reset não contabilizam essas streams ativas, permitindo que um cliente exceda os limites de concorrência configurados e esgote os recursos de CPU e memória do servidor.

Um invasor remoto não autenticado pode causar o consumo excessivo de CPU do servidor devido a uma complexidade algorítmica ineficiente no analisador de inteiros do cabeçalho. A função `Bandit.Headers.parse integer/2` em `lib/bandit/headers.ex` processa números dígito por dígito sem limite na contagem de dígitos, alocando um novo bignum a cada etapa. Isso resulta em um tempo de processamento quadrático em relação ao comprimento da entrada. O problema é acionado ao fornecer um valor de `content-length` ou uma porta `Host` ou `:authority` composta por milhares de dígitos. Isso ocorre na entrada bruta da requisição via HTTP/1 e HTTP/2 antes de qualquer verificação de intervalo. Em ambientes HTTP/2, um invasor pode usar o armazenamento da tabela dinâmica HPACK para amplificar o efeito, enviando um valor grande uma vez e referenciando-o em fluxos subsequentes para manter o servidor ocupado com tráfego mínimo.

Um invasor remoto não autenticado pode esgotar a memória do servidor através do processo de remontagem de fragmentos WebSocket. A função `Bandit.WebSocket.Connection` verifica a variável `max fragmented message size` em relação aos bytes de carga útil recebidos, mas não limita o número total de fragmentos. Ao enviar uma mensagem fragmentada composta por inúmeros quadros de continuação de 1 byte, um invasor pode consumir significativamente mais memória do que o limite configurado. Por exemplo, um fragmento de 1 byte requer aproximadamente 150 a 170 bytes de memória do servidor. Além disso, o envio de quadros Ping entre fragmentos permite que a conexão permaneça ativa além do tempo limite de inatividade.

Uma interpretação inconsistente de requisições HTTP, conhecida como HTTP Request/Response Smuggling, existe no leitor de corpo fragmentado (chunked body reader) do HTTP/1.1. Isso permite que um invasor remoto não autenticado contrabandee uma segunda requisição através de um proxy front-end via uma extensão de fragmento que contenha um LF (Line Feed) simples. O problema ocorre no arquivo `lib/bandit/http1/socket.ex`, onde o leitor de fragmentos aceita a linha de tamanho do fragmento até o primeiro CRLF e descarta o conteúdo após o caractere `;` sem validá-lo contra a gramática `chunk-ext` da RFC 9112. Consequentemente, bytes de controle como LF e CR simples são permitidos. Se um proxy front-end tratar um LF simples como um final de linha, ele poderá interpretar o fluxo como uma única requisição, enquanto o Bandit o interpretará como uma requisição pipelined separada, potencialmente ignorando os controles de acesso do proxy. Este problema afeta apenas implantações que utilizam um proxy front-end que trata um LF simples como final de linha e encaminha corpos fragmentados sem alterações.

Um invasor remoto não autenticado pode manter processos de stream abertos indefinidamente no leitor de corpo de requisição HTTP/2. Isso ocorre porque a função `do read data/4` em `lib/bandit/http2/stream.ex` redefine a contagem regressiva do `read timeout` sempre que um frame WINDOW UPDATE ou um frame SETTINGS vazio é recebido. Como esses frames não entregam dados do corpo, mas ainda assim encerram o período de espera, um cliente pode enviar esses frames de 9 bytes repetidamente para manter o `read body` bloqueado. Isso permite que o invasor ocupe o processo de stream e quaisquer recursos mantidos pela aplicação durante a operação de leitura em múltiplos streams e conexões.

Um invasor remoto não autenticado pode definir `conn.host` e `conn.port` com valores que violam a gramática de host da RFC 3986, utilizando a autoridade de um alvo de solicitação HTTP/1 em forma absoluta ou de autoridade. Embora o software valide o cabeçalho `Host` e retorne um erro 400 se estiver malformado, a autoridade dentro do alvo da solicitação tem precedência, conforme exigido pela RFC 9112. A função `determine host and port!/4` em `lib/bandit/pipeline.ex` passa essa autoridade para a aplicação sem a devida validação. Isso permite a inserção de bytes NUL, DEL e não-ASCII, literais de IP inválidos e portas fora do intervalo 1..65535. Aplicações que constroem URLs absolutas usando `conn.host`, como através de `Plug.Conn.request url/1` ou auxiliares de URL do Phoenix, podem emitir links com uma autoridade escolhida pelo invasor. Para solicitações `CONNECT`, a string da porta não analisada é colocada em `conn.port`, o que pode fazer com que `Plug.Conn.request url/1` gere um erro, já que `Plug.Conn.port number/0` espera um número inteiro.

O consumo descontrolado de recursos permite que um invasor remoto não autenticado mantenha processos de stream HTTP/2 indefinidamente. Ao enviar um fluxo de pequenos frames `WINDOW UPDATE` ou frames `SETTINGS` vazios, um invasor pode reiniciar o prazo de 15 segundos para processos de stream bloqueados. Isso ocorre por dois caminhos independentes: um onde `Bandit.HTTP2.Connection.finish data/5` coloca novamente envios parcialmente avançados em `pending sends` com um carimbo de data/hora `expires at` atualizado, e outro onde `Bandit.HTTP2.Stream.send data/3` recursa a cada `WINDOW UPDATE` de stream e reativa um `read timeout` novo. Esse comportamento mantém vivo o processo de stream bloqueado, seu estado Plug e recursos associados, podendo esgotar os processos e a memória do servidor.

Uma neutralização inadequada de sequências CRLF permite que um invasor remoto não autenticado introduza caracteres de Retorno de Carro (CR), Alimentação de Linha (LF) ou Nulo (NUL) em cabeçalhos de requisição visíveis para a aplicação via HTTP/2. A função `Bandit.HTTP2.Stream.read headers/1` valida o posicionamento e a unicidade de pseudo-cabeçalhos, a capitalização de nomes de cabeçalhos, cabeçalhos específicos de conexão, o valor `te` e o `content-length`, mas não verifica os valores dos campos. Como o HPACK transporta octetos arbitrários, um bloco HEADERS cujos valores de campo contenham `r`, ` ` ou `0` é decodificado sem erro e os valores são inseridos em `conn.req headers` inalterados. Enquanto o caminho HTTP/1 já rejeita esses octetos, o HTTP/2 não o fazia. O risco reside na forma como uma aplicação downstream consome os valores dos cabeçalhos, como ao anexar um verbatim a um log de texto simples ou concatená-lo em uma requisição upstream. Adicionalmente, um pseudo-cabeçalho `:authority` duplicado poderia ser aceito, com a primeira instância vencendo silenciosamente como `conn.host` enquanto um valor conflitante permanecia visível para a aplicação.

Um invasor remoto não autenticado pode fixar um número ilimitado de processos de stream HTTP/2 indefinidamente ao explorar o controle de fluxo no nível da conexão. Quando o corpo de resposta de um stream excede a janela de envio no nível da conexão HTTP/2, o `Bandit.HTTP2.Connection` coloca os bytes restantes e um fechamento de resposta em fila em `pending sends`, fazendo com que o processo do stream bloqueie permanentemente durante uma chamada síncrona ao processo de conexão. Como não há limite para essa espera e a fila não é limpa, as solicitações `RST STREAM` do cliente nunca são lidas, e frames PING periódicos impedem que os timeouts de leitura do nível de transporte sejam disparados. Isso permite que um invasor fixe processos, estado do Plug e recursos associados, como conexões upstream agrupadas em um Plug de proxy reverso, ao atingir endpoints com respostas maiores que a janela de conexão e manter a conexão ativa com PINGs.

Um problema de complexidade algorítmica ineficiente permite a negação de serviço remota não autenticada via exaustão de CPU durante a remontagem de fragmentos de WebSocket. A função `oversize message?/2`, chamada a partir de `handle frame/3` em `lib/bandit/websocket/connection.ex`, anexa frames de continuação não finais a um iolist aninhado à esquerda e remede a buffer inteira usando `IO.iodata length/1` para cada frame. Isso resulta em um trabalho de remontagem quadrático (O(n^2)) em relação ao número de frames de continuação. Embora o limite `max fragmented message size` restrinja o total de bytes, ele não limita a contagem de frames. Um invasor pode enviar inúmeros frames de continuação pequenos para exaurir os recursos da CPU, potencialmente esgotando o servidor e negando serviço a usuários legítimos. Este problema afeta especificamente aplicações que servem endpoints de WebSocket através do Bandit, incluindo aplicações Phoenix que utilizam o Bandit como adaptador HTTP.

Um invasor remoto não autenticado pode causar a negação de serviço via exaustão de memória. A função `read data/2` em `Elixir.Bandit.HTTP1.Socket` ignora a opção `:length` ao processar corpos de requisição HTTP/1 chunked. Especificamente, a função `do read chunked data!/5` armazena cada chunk recebido em um iolist sem limitar o corpo acumulado ao limite configurado, materializando todo o corpo como um único binário. Como esse processo ocorre antes do roteamento e da autenticação em endpoints Phoenix padrão, o envio de uma única requisição POST com o cabeçalho `Transfer-Encoding: chunked` e um corpo arbitrariamente grande pode exaurir a memória do processo BEAM, levando à terminação pelo OOM killer do sistema operacional.

Um loop infinito na função `do read chunked data!/5` em `lib/bandit/http1/socket.ex` permite que atacantes remotos não autenticados causem uma negação de serviço através da exaustão de processos trabalhadores. O problema ocorre porque a função termina apenas quando a linha do último chunk é seguida imediatamente por uma linha de trailer vazia, enquanto a RFC 9112 §7.1.2 permite zero ou mais campos de trailer. Quando trailers estão presentes, o processo entra em um estado de recursão com estado inalterado, prendendo o processo trabalhador durante toda a conexão TCP. Um pequeno número de requisições chunked simultâneas em conformidade com a RFC contendo campos de trailer pode exaurir o pool de trabalhadores, tornando o servidor inoperante. Isso pode ocorrer mesmo com tráfego legítimo encaminhado por proxies como NGINX e HAProxy.

Um invasor remoto não autenticado pode causar a negação de serviço via exaustão de memória quando a compressão permessage-deflate do WebSocket está habilitada. O problema ocorre porque a função `inflate/2` em `Elixir.Bandit.WebSocket.PerMessageDeflate` chama `:zlib.inflate/2` sem um limite de tamanho de saída e materializa a carga útil descompactada como um único binário usando `IO.iodata to binary/1`. Embora o `websocket options.max frame size` limite o tamanho do quadro compactado, ele não limita a saída descompactada. Consequentemente, um quadro compactado de alta proporção pode forçar alocações de heap em escala de GiB, esgotando a memória do nó BEAM e disparando a interrupção por falta de memória (OOM kill). Isso requer que tanto o `websocket options.compress` no nível do servidor quanto a opção `compress: true` por upgrade em `WebSockAdapter.upgrade/4` estejam habilitados.