Peter Ullrich

Ocorre uma injeção de XML no codificador XML Saxy porque a função `Saxy.Encoder.cdata/1` serializa nós `{:cdata, characters}` envolvendo caracteres entre `<![CDATA[` e `]]>` sem neutralizar a carga útil. Enquanto outros caminhos escapam metacaracteres XML, o caminho CDATA não trata a substring `]]>`, que é a única maneira de encerrar uma seção CDATA. Um invasor pode fornecer texto não confiável contendo `]]>` para encerrar a seção prematuramente, permitindo que a entrada subsequente seja analisada como marcação XML. Isso possibilita a injeção de elementos e atributos irmãos arbitrários na estrutura do documento. Este problema afeta serviços que geram envelopes SOAP, feeds RSS ou Atom, sitemaps, SVG ou exportações XML a partir de conteúdo fornecido pelo usuário. A vulnerabilidade é acionada ao usar `Saxy.XML.cdata/1` em conjunto com `Saxy.encode!/2` ou `Saxy.encode to iodata!/2`.

O codificador XML não valida nem escapa o alvo e o conteúdo de instruções de processamento, escrevendo-os literalmente no documento de saída. Como a sequência `?>` encerra uma instrução de processamento, um invasor pode usar essa sequência para fechar a construção prematuramente e injetar elementos arbitrários, atributos e outras instruções de processamento no documento serializado. Isso ocorre porque o codificador concatena campos sem verificá-los em relação às restrições da especificação XML. A função `Saxy.XML.processing instruction/2` é um construtor público que permite a herança dessa falha. Isso pode levar à injeção de XML, resultando em registros forjados, folhas de estilo injetadas ou conteúdo ativo quando a saída é processada por um analisador downstream ou navegador. O problema é acionado quando um nó `{:processing instruction, name, content}` é passado para `Saxy.encode!/2` ou `Saxy.encode to iodata!/2` usando entradas não confiáveis.

Um problema de injeção de XML existe no codificador do Saxy. O `Saxy.Encoder` não neutraliza a sequência `--` no conteúdo de comentários XML porque a função `escape comment/2` retorna o binário do comentário inalterado em cada cláusula e apenas adiciona um espaço quando o comentário termina em um único `-`. Consequentemente, nem um `--` interno nem um `-->` completo são escapados ou rejeitados antes que o codificador envolva o conteúdo nos delimitadores. Quando uma aplicação serializa texto controlado por um invasor como um comentário através de `Saxy.XML.comment/1` ou um filho de formulário simples bruto `{:comment, text}`, o invasor pode fechar o comentário prematuramente com `-->` e injetar marcações irmãs arbitrárias no documento serializado. Isso permite a execução de cross-site scripting armazenado onde o documento é renderizado como HTML ou SVG, ou a falsificação de dados quando consumido por outro processador XML. Este problema afeta apenas aplicações que serializam texto não confiável usando `Saxy.encode!/2` ou `Saxy.encode to iodata!/2`.

A validação inadequada da quantidade especificada na entrada no módulo `JSON` da biblioteca padrão do Elixir permite que um invasor não autenticado cause a negação de serviço através do esgotamento de CPU e memória ao fornecer um documento JSON especialmente criado. As funções `JSON.decode/1` e `JSON.decode!/1` utilizam `erlang:binary to integer/1` para converter literais inteiros sem limitar seu comprimento. Consequentemente, um literal inteiro com um milhão de dígitos consome de 100 a 300 vezes mais CPU do que uma string do mesmo comprimento, e literais que excedam aproximadamente 1,29 milhão de dígitos disparam um `SystemLimitError`. Aplicações geradas por `phx.new` são particularmente suscetíveis, pois decodificam corpos de requisição usando `Plug.Parsers` antes da roteamento e autenticação.

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 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.

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 canal lateral de temporização no fallback Curve25519 em pure-Erlang permite a recuperação de uma chave privada X25519 de longo prazo. A implementação utiliza uma escada de Montgomery recursiva na função `jose jwa x25519:curve25519/2`, onde operações como `jose jwa x25519:montgomery add/3` e `jose jwa x25519:montgomery double/1` dependem de aritmética de bignum do Erlang dependente de valor. Consequentemente, o tempo de execução dos pontos de entrada públicos, incluindo `jose jwa x25519:scalarmult/2`, `jose jwa x25519:x25519/2`, `jose jwa x25519:x25519 base/1` e `jose jwa x25519:sk to pk/1`, varia com base na chave privada. Isso é explorável quando um serviço descriptografa mensagens ECDH-ES (JWE) fornecidas por um invasor via `JOSE.JWK.box decrypt ecdh es/2`, que chama `jose jwa curve25519:x25519 shared secret/2`. Um invasor que meça o tempo de descriptografia pode recuperar a chave privada bit a bit, comprometendo a confidencialidade e a autenticidade dos dados.

Um tratamento inadequado de dados altamente compactados, conhecido como amplificação de dados, permite que um invasor remoto esgote a memória de um nó usando um token JWE pequeno e manipulado. A função `jose jwe zip:uncompress/2` em `src/jwe/jose jwe zip.erl` descompacta o texto simples compactado via DEFLATE de um JWE que contém o cabeçalho `zip: DEF`, chamando `zlib:inflate/2` no fluxo controlado pelo invasor, sem limites para o tamanho da saída ou a taxa de inflação. Isso pode fazer com que um token de alguns kilobytes se transforme em centenas de megabytes ou gigabytes. A descompactação ocorre automaticamente durante a descriptografia via `jose jwe:block decrypt/2` (ou `JOSE.JWE.block decrypt/2` em Elixir) antes que a carga útil seja inspecionada. Usando algoritmos de gerenciamento de chaves assimétricas como RSA-OAEP ou ECDH-ES, um invasor precisa apenas da chave pública do destinatário para criar o token, sem necessidade de autenticação. Isso pode travar o BEAM e causar a negação de serviço.

O módulo `jose jwa pkcs1` contém um oráculo de preenchimento Bleichenbacher em sua descriptografia RSAES-PKCS1-v1 5 em pure-Erlang. A função `eme pkcs1 decode/2` retorna a mensagem recuperada para preenchimentos PKCS#1 v1.5 válidos, mas retorna um erro distinto caso contrário. Além disso, `rsaes pkcs1 decrypt/2` retorna `{error, {badsize, }}` quando a verificação de comprimento falha. A implementação não aplica contra-medidas de rejeição implícita, não substituindo um texto simples pseudo-aleatório determinístico em falhas de preenchimento, o que vaza um sinal de conformidade de preenchimento. Além disso, o uso de `crypto:mod pow/3` não cegado na função `dp/2` permite que a verificação de preenchimento seja distinguível via ataques de tempo, mesmo que os valores de erro sejam normalizados. Um invasor não autenticado com a chave RSA pública pode enviar textos cifrados para um endpoint de descriptografia que desempacota chaves JWE RSA1 5 ou chama `decrypt private/3` com `rsa pkcs1 padding` para recuperar o texto simples, como chaves de criptografia de conteúdo, ou forjar assinaturas usando consultas adaptativas de texto cifrado escolhido. Este problema ocorre apenas quando a opção `crypto fallback` está habilitada e o runtime OTP não fornece descriptografia RSA1 5 nativa.

A função `jose jwk:shared secret/2` (exposta em Elixir como `JOSE.JWK.shared secret/2`) é utilizada para derivar um segredo compartilhado ECDH a partir de duas JSON Web Keys (JWKs). Existe uma falha onde a função apenas corresponde quando ambas as JWKs possuem o mesmo módulo de tipo de chave (`kty`). Se os tipos de chave diferirem, como uma chave EC e uma chave RSA, a cláusula de fallback reinvoca a função com argumentos idênticos, criando um loop recursivo de cauda ilimitado. Este loop consome 100% da CPU de um escalonador Erlang. Um invasor que forneça uma JWK especialmente manipulada pode desencadear esse comportamento, e solicitações repetidas podem esgotar todos os escalonadores disponíveis, resultando em uma negação de serviço.

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 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 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 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 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 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.