Jonatan Männchen

A neutralização inadequada de sequências de escape, meta ou de controle permite que um publicador de pacotes malicioso ou um servidor de repositório hostil injete sequências de controle de terminal na saída de tarefas Mix. O software imprime strings do repositório de pacotes e do serviço de busca de documentação diretamente no terminal através de `Hex.Shell.info/1` e `Hex.Shell.error/1`, sem neutralizar caracteres de controle. Isso afeta metadados de pacotes, trechos de configuração em `mix hex.info`, resultados de busca em `mix hex.package search` e `mix hex.search`, listagens de proprietários e organizações, URLs de publicação e patrocínio, o nome de usuário autenticado em `mix hex.user`, identidades de política em `mix hex.policy` e corpos de erro de API renderizados por `Hex.Utils.print error result/1`. Um invasor pode incorporar sequências de escape ANSI — como movimento de cursor, exclusão de linha, retornos de carro e gravações de área de transferência OSC 52 — ou sobreposições bidirecionais Unicode para forjar URLs exibidas, descrições de pacotes e comandos sugeridos, ocultar a saída real ou escrever na área de transferência. Isso pode ser acionado por qualquer desenvolvedor que execute uma busca de documentação que exiba um pacote malicioso.

O AshAuthentication permite a divulgação de digests de senhas de usuários para leitores do armazenamento de auditoria. O add-on `audit log` constrói o `extra data` de cada entrada na função `AshAuthentication.AddOn.AuditLog.Auditor.build extra data/4`, que recebe o `:actor` do contexto de callback da ação literalmente. Quando uma ação auditada é invocada com `actor:` definido como um registro de usuário, esse registro—incluindo o atributo `hashed password`—é depositado na entrada de auditoria. Embora outras identidades sejam reduzidas via `AshAuthentication.user to subject/1` e os parâmetros sejam filtrados, o ator permanece sem filtragem. Definir o atributo `sensitive?: true` não é eficaz, pois redige apenas a saída de `inspect/1` e não a codificação JSON ou o armazenamento de termos brutos. A exploração requer acesso de leitura independente ao armazenamento de auditoria (ex: credenciais de banco de dados, backups ou transportadores de log), permitindo ataques de senha offline contra contas ativas. A persistência desses dados depende da camada de dados; armazenamentos de termos brutos os mantêm literalmente, enquanto armazenamentos SQL podem descartar a entrada, a menos que o recurso de usuário derive `Jason.Encoder`.

Uma falha de traversal de caminho relativo no módulo zip da stdlib permite a gravação de arquivos fora do diretório de extração pretendido ao processar um arquivo zip manipulado. As funções `zip:unzip/1,2` e `zip:extract/1,2` utilizam `zip:check dir level/2` para validar caminhos de entrada rastreando a profundidade do diretório com um contador inteiro. Como a validação apenas rejeita caminhos onde o valor final do contador é negativo, um caminho como `../x/y` pode fazer com que o contador fique negativo durante a travessia e depois retorne a zero, ignorando a verificação e resolvendo para um local fora do diretório de extração via `add cwd`. Este problema está localizado no arquivo `lib/stdlib/src/zip.erl`.

O analisador de corpo de requisição `Plug.Parsers.MULTIPART`, utilizado para uploads de arquivos e formulários multipart, não aplica o limite `:length` a todos os recursos consumidos. O analisador contabiliza apenas os bytes do corpo da parte, ignorando os bytes do cabeçalho da parte e partes com corpos vazios. Um invasor remoto não autenticado pode explorar isso enviando uma única requisição composta por inúmeras partes de arquivo com corpo vazio e um nome de arquivo não vazio no `Content-Disposition`. Esse processo desencadeia a criação de um arquivo temporário via `Plug.Upload` e retém uma estrutura `Plug.Upload` para cada parte, resultando em crescimento ilimitado de memória e exaustão de espaço em disco e inodes. O problema está associado ao arquivo `lib/plug/parsers/multipart.ex` e às funções `Plug.Parsers.MULTIPART.parse multipart/2`, `Plug.Parsers.MULTIPART.parse multipart headers/5`, `Plug.Parsers.MULTIPART.parse multipart body/4` e `Plug.Parsers.MULTIPART.parse multipart file/4`.

A neutralização inadequada de delimitadores de parâmetros permite que um invasor injete ou substitua atributos de cookies HTTP. A função `encode/2` em `Plug.Conn.Cookies` constrói o cabeçalho de resposta Set-Cookie interpolando o valor do cookie e seus atributos de caminho, domínio, `same site` e atributos extras sem neutralizar o delimitador ';'. Se uma aplicação colocar dados controlados por um invasor em um valor ou atributo de cookie, como através da função `put resp cookie/4`, um invasor pode injetar um ';' para anexar ou substituir atributos como o escopo de Domínio e Caminho, ou remover as flags Secure e HttpOnly. Isso pode possibilitar cookie tossing e fixação de sessão. Embora retornos de carro, alimetações de linha e bytes nulos sejam rejeitados, impedindo a divisão de resposta HTTP, a injeção de atributos via ';' permanece possível.

Um invasor não autenticado pode causar a negação de serviço em qualquer endpoint que monte um socket Phoenix com um transporte de canal acessível, como WebSocket ou LongPoll. O problema reside na rotina `Elixir.Phoenix.Socket`:handle in/4 dentro do arquivo lib/phoenix/socket.ex. Como os transportes do Phoenix não limitam o número de canais que um único processo de transporte pode ingressar, um cliente pode enviar um número ilimitado de mensagens phx join através de uma única conexão. Isso gera processos de canal excessivos, podendo esgotar o limite máximo de processos do BEAM e impedir que a máquina virtual inicie novos processos para tráfego legítimo. Essa amplificação ocorre dentro de uma única conexão, tornando ineficazes os limites de conexão e a limitação de taxa na camada de rede.

O cliente JavaScript Presence no phoenix contém uma verificação inadequada de condições excepcionais que permite que um invasor com acesso comum ao canal cause uma negação de serviço persistente no lado do cliente para todos os visualizadores de um tópico de canal de presença. O problema reside no arquivo `assets/js/phoenix/presence.js` dentro das rotinas `Presence.syncState()` e `Presence.syncDiff()`. O cliente utiliza um teste de verdade simples (`state[key]`) em vez de uma verificação de propriedade própria para verificar se uma presença existe. Como as chaves de presença são controladas pelo invasor, um usuário pode fornecer uma chave que corresponda a um nome de membro do `Object.prototype` (como ` proto `, `constructor`, `toString` ou `hasOwnProperty`). Isso faz com que a busca retorne o `Object.prototype` integrado em vez de `undefined`, levando o código a tentar ler `.metas.map(...)` do protótipo, o que gera um `TypeError` não capturado. Essa exceção impede que o estado local seja atualizado e evita que o `onSync()` seja disparado. Como o servidor continua a enviar a chave maliciosa, a sincronização permanece interrompida para todos os visualizadores do tópico até que o invasor saia. Trata-se de uma confusão de tempo de leitura do objeto protótipo e não de poluição de protótipo.

Existe uma injeção de caminho de URL no adaptador Microsoft Graph do Swoosh. O componente `Swoosh.Adapters.MsGraph` constrói a URL de requisição da API do Microsoft Graph interpolando o endereço de e-mail do remetente no caminho `/users/{from}/sendMail` sem validação ou codificação percentual (percent-encoding). Em aplicações onde o endereço `from` é derivado de entradas não confiáveis ou influenciadas pelo usuário, um invasor pode usar caracteres especiais de URL, como `/`, `?` ou `#`, na parte local do endereço para escapar do segmento de caminho pretendido. Isso permite que o invasor reescreva o caminho da requisição e a string de consulta, redirecionando a requisição POST autenticada para outros endpoints do Graph dentro dos escopos do token, utilizando o token de portador (bearer token) da aplicação.

Atacantes não autenticados podem esgotar a memória do BEAM e travar o servidor ao transmitir um corpo de requisição unária grande ou em fluxo lento (slow-trickle). A função `read full body/3` em 'Elixir.GRPC.Server.Adapters.Cowboy.Handler' acumula cada chunk recebido em um único binário crescente sem limite de tamanho. Além disso, quando o cliente omite o cabeçalho `grpc-timeout`, o tempo limite de leitura por chunk é definido como infinito, permitindo que um cliente de fluxo lento mantenha a conexão indefinidamente enquanto a memória cresce. Uma única conexão é suficiente para esgotar a memória do servidor e travar o nó.

Atacantes autenticados podem acessar ou modificar recursos pertencentes a outros usuários ao contrabandear um valor conflitante para qualquer campo vinculado ao caminho via string de consulta ou corpo da requisição. Isso ocorre na função `map request/5` em `Elixir.GRPC.Server.Transcode` (lib/grpc/server/transcode.ex), onde `Map.merge/2` é utilizado com vinculações de caminho como o primeiro argumento, atribuindo-lhes a menor precedência de mesclagem. Consequentemente, uma requisição como 'GET /users/me/profile?user id=victim' ou uma requisição POST contendo `user id` no corpo resulta em uma estrutura protobuf decodificada onde o campo vinculado ao caminho é sobrescrito pelo valor fornecido pelo atacante. Isso permite a evasão de manipuladores que utilizam esses campos para autorização, verificações de propriedade ou escopo de multi-tenancy. Este problema requer que a transcodificação HTTP-para-gRPC esteja habilitada.

O Consumo Não Controlado de Recursos no módulo Version da biblioteca padrão permite que um invasor cause a negação de serviço através da exaustão de CPU e memória. O analisador de versão converte componentes numéricos em inteiros sem limitar seu comprimento, forçando uma conversão de base-10 para inteiro de precisão arbitrária superlinear e não cedente através de `String.to integer/1` (também conhecido como `:erlang.binary to integer/1`). Este processo trava um agendador BEAM, e componentes maiores podem disparar um `SystemLimitError` não capturado que derruba o processo solicitante. Uma string de aproximadamente um megabyte é suficiente para disparar este problema, e nenhuma autenticação é necessária. O problema é acessível através da rotina `parse digits/2` em `lib/version.ex` e pontos de entrada públicos, incluindo `Version.parse/1`, `Version.parse!/1`, `Version.match?/3`, `Version.compare/2` e `Version.parse requirement/1`.

A neutralização inadequada de sequências CRLF (Carriage Return e Line Feed) em cabeçalhos HTTP permite a injeção de cabeçalhos HTTP. A função `Tesla.Multipart.add content type param/2` anexa strings fornecidas pelo chamador à lista `content type params` multipart sem validar caracteres `r` ou ` `. Posteriormente, a função `Tesla.Multipart.headers/1` une esses parâmetros textualmente para construir o valor do cabeçalho Content-Type de saída. Um parâmetro contendo `r ` divide a linha do cabeçalho, permitindo que cabeçalhos arbitrários sejam injetados na solicitação HTTP de saída. Qualquer aplicação que encaminhe entradas não confiáveis, como charset ou strings de parâmetros fornecidas pelo usuário, para a função `Tesla.Multipart.add content type param/2` é afetada. Isso pode resultar na falsificação de cabeçalhos de solicitação de saída ou potencial contrabando de requisições (request smuggling) contra o servidor upstream.

O manuseio inadequado de dados altamente comprimidos permite a negação de serviço por meio de uma bomba de descompressão em corpos de resposta HTTP. Quando `Tesla.Middleware.DecompressResponse` ou `Tesla.Middleware.Compression` é utilizado em um pipeline de middleware, os corpos de resposta são descomprimidos de forma ávida sem limite de tamanho. A função `decompress body/2` passa o corpo completo da resposta para `:zlib.gunzip/1` ou `:zlib.unzip/1` sem limitar o tamanho da saída. Além disso, a função `compression algorithms/1` divide o cabeçalho `content-encoding` por vírgulas, e a `decompress body/2` recursa para cada token. Um servidor que anuncie múltiplos tokens gzip no cabeçalho `content-encoding` pode desencadear passagens de descompressão recursivas, resultando em amplificação exponencial de dados, onde uma pequena carga útil de rede expande-se para gigabytes de BEAM heap (área de memória utilizada pela máquina virtual Erlang), esgotando a memória e travando ou congelando o processo de chamada.

O manuseio inadequado da distinção entre maiúsculas e minúsculas em `Tesla.Middleware.FollowRedirects` permite o vazamento de credenciais para origens de terceiros em redirecionamentos de origem cruzada. O middleware tenta remover cabeçalhos sensíveis comparando-os com uma lista de filtros em letras minúsculas contendo `authorization` e `host`. No entanto, como o Tesla preserva as chaves dos cabeçalhos exatamente como fornecidas pelo chamador, sem normalização, cabeçalhos que utilizam a capitalização canônica, como `Authorization`, não coincidem com o filtro em minúsculas e são encaminhados para o destino do redirecionamento. Um atacante que possa controlar a resposta `Location:` — por meio de seu próprio endpoint, um upstream de redirecionamento aberto ou uma origem comprometida — pode capturar tokens de portador ou outros materiais de autorização. Isso ocorre quando a aplicação utiliza `Tesla.Middleware.FollowRedirects` e define cabeçalhos com chaves que não estejam em letras minúsculas.

A codificação ou escape inadequado de saída permite a injeção de cabeçalho de parte multipart por meio de valores de parâmetro `Content-Disposition` não escapados. A função `part headers for disposition()` interpola parâmetros de disposição sem validar caracteres de retorno de carro (`r`), alimentação de linha (` `) ou aspas duplas. Esses valores são recebidos do chamador via `add field()` (parâmetro `name`), `add file()` (parâmetro `filename`) e `add file content()` (parâmetro `filename` e outras opções de disposição). Um caractere de aspas duplas pode fechar prematuramente um parâmetro citado, enquanto sequências `r ` podem encerrar o cabeçalho `Content-Disposition` para iniciar um novo cabeçalho forjado ou encerrar o bloco de cabeçalhos para prepender bytes ao corpo da parte. Além disso, o caminho do nome de arquivo padrão em `add file()` utiliza `Path.basename()`, que não remove retornos de carro ou alimentações de linha.

Um problema no Tesla.Adapter.Mint permite a negação de serviço via exaustão da tabela de átomos. A função `open conn/2` converte o esquema de URL de requisições de saída em um átomo BEAM usando `String.to atom(uri.scheme)` sem validação de lista de permissões. Átomos BEAM são entradas permanentes que não são coletadas pelo garbage collector e são limitadas a uma tabela de aproximadamente 1.048.576 entradas. Um invasor capaz de influenciar a URL da requisição — por meio de recursos de encaminhamento de URL no nível da aplicação, como webhooks, proxies ou importadores, ou via um cabeçalho Location quando o `Tesla.Middleware.FollowRedirects` está ativo — pode criar um novo átomo para cada requisição variando a string do esquema. Quando a tabela de átomos fica cheia, a máquina virtual falha, resultando no desligamento completo da aplicação.

Uma falha de autorização no módulo `Elixir.Oban.Web.Jobs.DetailComponent` permite a substituição não autorizada do trabalhador de um job. O manipulador `handle event("save-job", ...)` não realiza verificações de autorização, ao contrário de outros manipuladores como cancel, delete e retry, que verificam privilégios via `can?/2`. Um usuário autenticado com acesso `:read only` pode enviar um evento de WebSocket LiveView `save-job` forjado para sobrescrever o campo de trabalhador de um job com qualquer outro módulo `Oban.Worker` existente na aplicação. Consequentemente, na próxima tentativa de execução, o Oban invocará a função `perform/1` no módulo escolhido pelo atacante em vez do pretendido. Isso ocorre quando o painel Oban.Web está implantado e acessível a usuários com privilégios limitados de gerenciamento de jobs.

O Consumo Não Controlado de Recursos no módulo `Elixir.Oban.Web.CronExpr` permite a exaustão de memória através da expansão ilimitada de intervalos de cron. Um invasor com permissões para agendar tarefas cron pode enviar uma expressão cron maliciosa. Quando um usuário com acesso ao painel de controle visualiza a lista de tarefas cron, a função `describe/1` é chamada para renderizar a expressão. A função `parse range/1` analisa os limites do intervalo usando `Integer.parse/1` sem verificação de limites, e os auxiliares `expand dom parts/1` e `expand dow parts/1` materializam o intervalo ansiosamente via `Enum.to list/1`. Esse processo pode levar à alocação de aproximadamente 2,4 GB de memória, resultando no travamento ou falha do nó BEAM (a Máquina Virtual Erlang).

O Consumo Não Controlado de Recursos no transporte SOCKS5 em `src/hackney socks5.erl` permite flooding. Embora o tempo limite fornecido pelo chamador seja aplicado durante a fase de negociação SOCKS5, a atualização da conexão para TLS através da função `ssl:connect/2` assume um tempo limite infinito por padrão, pois a variável `Timeout` não é encaminhada. Consequentemente, um proxy SOCKS5 malicioso que complete o handshake e então fique inativo ou envie um TLS ServerHello parcial pode fazer com que o processo de conexão bloqueie indefinidamente, ignorando as opções `connect timeout` ou `recv timeout`.

A Neutralização Imprópria de Sequências CRLF, também conhecida como CRLF Injection, permite a Divisão de Requisição/Resposta HTTP (HTTP Request/Response Splitting). O código de upgrade de WebSocket em `src/hackney ws.erl` copia o host, caminho, cabeçalhos (`ExtraHeaders`) e opções de protocolos do mapa de opções fornecido pelo chamador para o registro interno `#ws data{}` em `init/1` e, em seguida, os insere literalmente na requisição de upgrade HTTP/1.1 bruta por concatenação binária em `do handshake/1`. Como nenhuma remoção de CRLF ou NUL é realizada nesses quatro pontos de injeção, um invasor que controle essas opções — por exemplo, encaminhando componentes de URL ou valores de cabeçalho de entradas não confiáveis para `hackney ws:start link/1` — pode injetar cabeçalhos HTTP arbitrários na requisição de upgrade de WebSocket de saída. Isso pode levar à injeção de cabeçalhos, falsificação de credenciais (credential spoofing) para o servidor upstream, envenenamento de logs e cache, ou contrabando de requisições (request smuggling) via proxies intermediários.