Eric Meadows-Jönsson

Um invasor remoto não autenticado pode causar exaustão de memória tanto na aplicação quanto no servidor de banco de dados. Isso ocorre quando a aplicação interpola dados fornecidos pelo usuário em `json extract path/2`, `field[^key]` ou `splice/1`. O Ecto armazena consultas preparadas em cache em uma tabela ETS sem limites de tamanho ou políticas de expulsão. Como os elementos de caminho JSON interpolados e as expansões de `splice/1` tornam-se parte da expressão da consulta em vez de parâmetros, cada chave ou comprimento de lista exclusivo cria uma nova entrada de cache. Ao usar ecto sql, cada entrada também gera uma nova instrução preparada na conexão do banco de dados. Essa memória não é liberada até que os processos sejam reiniciados.

Uma validação inadequada da quantidade especificada na entrada no módulo `URI` da biblioteca padrão do Elixir permite que um invasor cause a negação de serviço através do esgotamento da CPU ao fornecer uma URL com um componente de porta excessivamente longo. A função `URI.parse/1` utiliza `String.to integer/1` dentro de `split authority/1` para converter a porta sem limitar seu comprimento, permitindo a criação de um bignum (um número inteiro grande) de até 1.262.592 dígitos decimais. Quando esta URI analisada é convertida de volta para texto via `URI.to string/1`, `inspect/1`, logging ou formatação de erro, ela utiliza `:erlang.integer to binary/1`. No Erlang/OTP 27, 28 e 29.0, esse processo de conversão é quadrático, o que significa que o tempo de CPU necessário aumenta significativamente conforme o número de dígitos cresce. Por exemplo, uma porta com 400.000 dígitos pode levar aproximadamente 2,6 segundos para ser renderizada, enquanto uma porta de 1 MB pode levar cerca de 18 segundos. Isso pode levar ao esgotamento da CPU em servidores que analisam e, posteriormente, registram ou ecoam URLs fornecidas pelo usuário em campos de formulário ou corpo JSON.

Um problema de loop infinito existe no módulo `erl tar` (e suas variantes `hex erl tar`, `mix hex erl tar` e `r3 hex erl tar`) ao extrair arquivos tar. Um invasor pode causar a negação de serviço fornecendo um membro GNU sparse manipulado onde o mapa esparso termina antes do tamanho real do membro. Durante a extração, a função `erl tar:extract/1,2` utiliza `erl tar:stream to file loop/3` para ler dados em blocos. Nas versões afetadas, a função `erl tar:do sparse read/3` corresponde a uma cláusula de trailing-hole antes de uma cláusula de comprimento zero, levando a uma recursão ilimitada que consome um escalonador e mantém o processo ocupado indefinidamente. Isso pode ser acionado com um arquivo de apenas 2048 bytes. A opção `{max size, N}` apenas previne isso se N for menor que o tamanho real do membro. A extração usando a opção `memory` não é afetada.

Um problema de path traversal existe onde um publicador de pacotes malicioso pode excluir um diretório fora do diretório ` build` do projeto e extrair arquivos de pacotes nele quando um desenvolvedor busca dependências. Isso ocorre porque o rebar3 usa o campo `app` de uma dependência do registro Hex para nomear a dependência sem validação. Especificamente, a função `rebar packages:parse deps/1` atribui o nome, e `rebar app utils:dep to app/7` constrói o caminho do diretório. Subsequentemente, `rebar fetch:download source online/2` exclui o diretório resolvido usando `rm -rf` e move o pacote buscado para dentro dele. Se um publicador definir o campo `app` com um valor contendo sequências de path traversal como `../../../../target`, o rebar3 excluirá e sobrescreverá o diretório para o qual o caminho resolve. Esse processo acontece antes que o `rebar.config.script` da dependência seja avaliado. A substituição de um diretório cujos conteúdos sejam posteriormente executados ou carregados pode levar à execução remota de código.

A validação inadequada do valor de verificação de integridade permite que um espelho de pacotes substitua um tarball ao utilizar o comando `mix hex.package fetch PACKAGE VERSION --output -`. O Hex normalmente compara as somas de verificação (checksums) interna e externa de um tarball baixado com o registro assinado do repositório; no entanto, o ramo de saída padrão escreve os bytes retornados pela função `Hex.SCM.fetch/3` sem essa comparação. Além disso, a função `Hex.SCM.fetch/3` não verifica tarballs recém-baixados. Quando um espelho configurado via `HEX MIRROR URL` ou `mirror url` fornece bytes alterados, o comando os imprime e sai com sucesso. Além disso, o Hex imprime diagnósticos na saída padrão, incluindo o corpo de respostas HTTP falhas ou avisos de API do cabeçalho `x-hex-message`. Um espelho pode responder a essas solicitações com um erro contendo um arquivo tar, que é então gravado na saída padrão antes do tarball verificado. Isso permite que um pipeline que descompacta a saída padrão extraia arquivos fornecidos pelo espelho, mesmo que a verificação de checksum falhe posteriormente.

Uma falha no mecanismo de proteção permite que o proprietário de um pacote, ou um invasor com acesso à conta, ignore o período de carência (cooldown) de lançamento. O cooldown, configurado via `cooldown` ou `HEX COOLDOWN`, normalmente retém versões com idade inferior a um período específico durante a resolução de dependências. No entanto, quando um lançamento travado no `mix.lock` é aposentado ou possui um aviso de segurança, as funções `Hex.RemoteConverger.build cooldown bypass/3` e `Hex.RemoteConverger.unsafe lock bypass/1` removem o cooldown para esse pacote e suas dependências para permitir que o `mix deps.update` migre para um lançamento seguro. Como a função `Hex.Registry.Cooldown.versions/2` verifica a liberação apenas pelo nome do pacote, um invasor pode publicar um lançamento malicioso e aposentar a versão travada atualmente, forçando o sistema a selecionar o novo lançamento malicioso independentemente de sua idade. Essa liberação também se estende a pacotes com o mesmo nome em outros repositórios. Este problema não afeta cooldowns configurados por meio de políticas de dependência de organização.

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.

Um tratamento inadequado de dados altamente compactados, conhecido como amplificação de dados, permite que um espelho de pacotes não confiável esgote a memória ou o espaço em disco de uma máquina que execute `mix deps.get`, `mix deps.update`, `mix hex.package fetch` ou `mix hex.docs fetch`. Isso ocorre quando um espelho é configurado via `HEX MIRROR URL`, `HEX MIRROR` ou `mirror url`. Detalhes técnicos incluem: - A função `Hex.HTTP.request/5` lê todo o corpo da resposta na memória e o descompacta usando `:zlib.gunzip/1` se o `Content-Encoding` contiver `gzip`, sem limites para o tamanho compactado ou descompactado. Isso afeta respostas de registro, pacotes, documentação e API. - Arquivos tarball de pacotes não possuem limites de tamanho de download. Na versão 2.5.1, todo o tarball é mantido na memória e gravado no cache antes que o limite de 16 MiB seja verificado durante a descompactação. - Os comandos `mix hex.docs fetch` e `mix hex.docs offline` gravam tarballs de documentação no disco e os extraem usando `:mix hex erl tar.extract/2` sem aplicar os limites de 16 MiB compactados e 128 MiB descompactados utilizados por `mix hex tarball:unpack docs/3`. - Respostas de registro são descompactadas antes que suas assinaturas sejam verificadas.

O manuseio inadequado de dados altamente compactados leva a um problema de amplificação de dados, onde um espelho de repositório não confiável ou um servidor que responde a solicitações de API pode esgotar a memória da VM Erlang. No módulo `hex repo`, as funções `get names()`, `get versions()`, `get package()` e `get policy()` descompactam as respostas do registro usando `zlib:gunzip/1` e decodificam o envelope assinado antes que a assinatura seja verificada. Isso permite que um espelho forneça uma pequena resposta compactada que se expande em um envelope de tamanho arbitrário. Além disso, o `hex api` decodifica respostas com o tipo de conteúdo `application/vnd.hex+erlang` através de `hex safe binary to term:safe binary to term/1`, que utiliza `binary to term(Binary, [safe])`. Embora a opção safe evite a criação de átomos, ela não limita o tamanho do termo decodificado, e a validação para rejeitar funções e portas ocorre apenas após a construção do termo.

Um problema de path traversal existe onde um publicador de pacotes malicioso pode causar a exclusão de diretórios fora do diretório de build do projeto. Isso ocorre porque o Gleam lê o campo `app` da API de releases do hex.pm e o utiliza como nome do diretório de build do pacote sem a validação adequada. Se uma dependência falhar na compilação, o Gleam utiliza a função `remove dir all` para excluir o diretório associado a esse nome. Um publicador poderia definir o campo `app` como um caminho absoluto ou um caminho relativo contendo componentes `..` para atingir diretórios arbitrários. Isso pode ser acionado por comandos como `gleam build`, `gleam check`, `gleam run`, `gleam test` ou `gleam export` quando um projeto depende de uma release maliciosa. O problema está especificamente ligado à função `hex manifest package` em `compiler-cli/src/dependencies.rs` e à função `ProjectPaths::build directory for package`.

Um problema de path traversal existe onde um publicador de pacotes malicioso pode excluir um diretório fora do diretório `deps` do projeto e extrair arquivos de pacotes nele quando um desenvolvedor busca dependências. Isso ocorre porque o Hex utiliza um rótulo `app` do registro assinado do repositório como o nome da aplicação da dependência sem a validação adequada nas funções `Hex.RemoteConverger.deps/2` e `Hex.Mix.to lock/1`. O Mix define o diretório de checkout como `deps/<app>`, e a função `Hex.SCM.update/1` executa `File.rm rf!/1` nesse diretório antes de descompactar o pacote. Como o hex.pm valida apenas o comprimento do rótulo, um publicador pode usar valores como `../../target` para atingir diretórios fora do escopo pretendido. Esse processo acontece durante o `mix deps.get` ou `mix deps.update` antes que qualquer código de dependência seja compilado, permitindo potencialmente que um invasor sobrescreva arquivos em diretórios nos quais a conta do desenvolvedor tem permissão de escrita, o que pode levar à execução de código.

A validação inadequada de certificados no hex core permite que um invasor capaz de interceptar conexões HTTPS se passe pelo hex.pm, repo.hex.pm ou outros servidores de repositório e API. Isso ocorre quando programas utilizam o adaptador HTTP padrão no Erlang/OTP 24, ou no OTP 25 quando os certificados CA do sistema operacional não podem ser carregados. O problema deriva da função `hex core:default config/0` que seleciona o adaptador `hex http httpc`. Quando `hex http httpc:http options/2` tenta verificar o certificado do servidor usando `public key:cacerts get/0`, uma falha nessa chamada (que ocorre por padrão no OTP 24 ou quando nenhum armazenamento de CA é encontrado no OTP 25) faz com que o adaptador envie a requisição sem opções de `ssl`. Consequentemente, a aplicação `ssl` utiliza padrões que não verificam o certificado do servidor em versões anteriores ao OTP 26. Versões do hex core anteriores a 0.11.0 são afetadas em todas as versões do OTP anteriores a 26, independentemente da disponibilidade do armazenamento de CA, pois nunca definem opções de `ssl`. Um invasor no caminho da rede pode completar o handshake TLS com qualquer certificado, permitindo a interceptação de chaves de API, tokens OAuth e chaves de repositório, além de alterar requisições e respostas de API.

A validação inadequada de certificados permite que um invasor capaz de interceptar conexões HTTPS se passe por um host do Hex. Isso ocorre quando os usuários configuram `cacerts path` (ou `HEX CACERTS PATH`) para um armazenamento de CA específico que exclui certas CAs, mas o software continua a confiar no armazenamento de CA integrado. Especificamente, a função `Hex.HTTP.SSL.ssl opts/1` constrói um callback `partial chain` usando o armazenamento integrado, independentemente da configuração de `cacerts path`. Consequentemente, a função `Hex.HTTP.SSL.partial chain/2` pode aceitar uma cadeia de servidores se qualquer certificado corresponder a uma chave pública no armazenamento integrado, ignorando o armazenamento de CA restrito do usuário. Um invasor que possua um certificado para o host emitido por uma CA integrada pode interceptar chaves de API, tokens OAuth e chaves de repositório, além de modificar respostas de API. A verificação de nome de host e as somas de verificação de pacotes permanecem ativas.

Um problema de alocação de memória existe na função `Decimal.round/3` que permite a Negação de Serviço (DoS). A função constrói o resultado completo para o número solicitado de casas decimais antes de aplicar a precisão do contexto, fazendo com que o consumo de memória cresça com base no argumento `places` em vez do tamanho do resultado. Para `places` positivos, o software anexa dígitos zero ao coeficiente como uma charlist; para `places` negativos, ele constrói uma charlist de dígitos zero. Um valor elevado, como -50.000.000, pode alocar aproximadamente 5,5 GB de memória, potencialmente esgotando os recursos disponíveis e causando a interrupção da BEAM VM. Em versões mais antigas, este problema manifesta-se como alto consumo de CPU devido a um loop executado para cada casa decimal. Aplicações estão expostas se passarem valores fornecidos pelo usuário para `Decimal.round/2` ou `Decimal.round/3` sem a devida limitação.

Uma interpretação inconsistente de requisições HTTP, conhecida como HTTP Request/Response Smuggling, permite que um servidor HTTP/1 malicioso dessincronize um intermediário e o cliente Mint em uma conexão agrupada. Isso pode levar ao envenenamento de respostas para requisições subsequentes que compartilham a mesma conexão. O problema ocorre porque a função `message body/1` em `lib/mint/http1.ex` seleciona o enquadramento chunked se `chunked` for a primeira codificação listada no campo `Transfer-Encoding` de uma resposta, enquanto a RFC 9112 exige o enquadramento chunked apenas quando `chunked` for a codificação final. Além disso, o Mint mantém incorretamente as conexões abertas após uma resposta HTTP/1.0 que transporta `Transfer-Encoding` e `Connection: keep-alive`, o que viola os requisitos da RFC 9112 de tratar tal enquadramento como defeituoso e fechar a conexão.

Um servidor HTTP/2 malicioso pode causar a negação de serviço ao esgotar a memória no host cliente. O problema ocorre porque o `Mint.HTTP2` aplica a configuração `max header list size` apenas ao tamanho compactado de um bloco de cabeçalho recebido, em vez da lista de cabeçalhos decodificada, conforme exigido pela RFC 9113. Um invasor pode usar campos indexados HPACK para criar um bloco compactado pequeno que se expande em uma lista decodificada muito grande. Especificamente, a função `join cookie headers/1` em `lib/mint/http2.ex` copia cada valor de `cookie` de uma resposta em um novo binário, o que pode levar à alocação de aproximadamente 1 GB para uma única resposta sob as configurações padrão. Esse esgotamento de memória pode travar o processo que detém a conexão ou toda a máquina virtual BEAM.

Um problema de alocação de recursos permite que um servidor HTTP/2 malicioso force um cliente a armazenar em buffer até aproximadamente 16 MiB por conexão em frames que deveriam ser rejeitados, resultando no consumo excessivo de memória do cliente. Isso ocorre porque a função `decode next/2` em `lib/mint/http2/frame.ex` valida o frame em relação à variável `max frame size` apenas após o recebimento de todo o payload declarado. Até que o payload esteja completo, o sistema retorna `:more`, fazendo com que o `Mint.HTTP2` armazene todos os bytes recebidos no buffer da conexão. Um servidor pode declarar um comprimento de frame de até 16.777.215 bytes e reter o último byte para manter esse buffer enquanto a conexão permanecer aberta. Isso pode levar ao esgotamento de memória em clientes que mantêm inúmeras conexões com origens não confiáveis, como proxies, crawlers ou remetentes de webhooks.

Um problema de expiração de sessão insuficiente na emissão de tokens OAuth permite que usuários cuja associação à organização ou sessão tenha terminado continuem a ler pacotes privados e tarballs de documentação. Isso ocorre porque a função `generate refresh token/4` em `lib/hexpm/oauth/jwt.ex` assina tokens de atualização com as mesmas reivindicações `iss`, `aud` e `scope` que os tokens de acesso, incluindo o escopo `repository:<org>`. O serviço de CDN que fornece repositórios privados autoriza o acesso com base na reivindicação `scope` após verificar a assinatura e as reivindicações de tempo, sem realizar uma consulta ao banco de dados. Consequentemente, a CDN não consegue distinguir entre tokens de acesso e tokens de atualização. Enquanto os tokens de acesso expiram em 30 minutos, os tokens de atualização permanecem válidos por 30 dias, estendendo o acesso somente leitura não autorizado a organizações às quais a conta pertencia no momento em que o token foi concedido.

Uma interpretação inconsistente de requisições HTTP, conhecida como HTTP Request/Response Smuggling, permite que um servidor HTTP/1 malicioso dessincronize um intermediário rigoroso e o cliente Mint em uma conexão agrupada. Isso pode levar ao envenenamento da fila de respostas, onde bytes de uma resposta são atribuídos a requisições subsequentes que compartilham a mesma conexão. O problema ocorre porque a função `chunk size/1` em `Mint.HTTP1.Parse` para no primeiro byte não hexadecimal da linha de tamanho do chunk de uma resposta fragmentada e retorna o restante sem exame. Subsequentemente, a função `decode body/5` em `Mint.HTTP1` descarta todos os bytes até o CRLF usando `Parse.ignore until crlf/1`. Isso resulta na aceitação de dígitos hexadecimais seguidos por bytes arbitrários, enquanto a RFC 9112 permite apenas extensões de chunk introduzidas por um `;`. Consequentemente, um intermediário rigoroso em relação à RFC pode rejeitar uma linha que o Mint aceita, causando uma divergência sobre os limites do chunk e o fim do corpo da resposta.

A validação inadequada de quantidades de entrada no módulo inets httpc permite que um servidor HTTP malicioso ou comprometido degrade a disponibilidade. O problema ocorre quando o servidor retorna um cabeçalho numérico contendo uma sequência excessivamente longa de dígitos. Especificamente, o arquivo `httpc handler.erl` utiliza a função `list to integer/1` para converter o cabeçalho `Content-Length` antes de compará-lo com `max body size`, o que significa que a verificação de tamanho não impede o processo de conversão. Conversões ilimitadas semelhantes existem na função `format response/1` para `Content-Length` e na função `get ms from retry after/1` para o cabeçalho `Retry-After`. Como a função de conversão suporta aritmética de precisão arbitrária, o processamento de até 1,26 milhão de dígitos pode consumir recursos significativos de CPU, causando atrasos de centenas de milissegundos por resposta para o processo solicitante.