José Valim

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 falha de arquivo temporário inseguro no Mix `deps.partition` permite que um usuário local execute código arbitrário como outro usuário. Durante a compilação particionada de dependências, a configuração do projeto é passada para as VMs de partição através de um arquivo em um diretório de nome fixo dentro do diretório temporário compartilhado do sistema. A função `Mix.Tasks.Deps.Partition.server/4` em `lib/mix/lib/mix/tasks/deps.partition.ex` utiliza `File.mkdir p/1` para criar este diretório, que não verifica o proprietário do diretório caso ele já exista. Um invasor local pode pré-criar o diretório e substituir o arquivo de configuração antes que a função `client/0` o leia. O cliente então decodifica o arquivo malicioso usando `:erlang.binary to term/1` e executa comandos de shell injetados através da opção `compile:` das dependências. Além disso, a natureza de leitura pública do arquivo de partição pode expor configurações do projeto a outros usuários locais. Este problema requer que a compilação particionada esteja ativada via variável `MIX OS DEPS COMPILE PARTITION COUNT` e um diretório temporário de sistema compartilhado.

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.

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 expor a base da chave secreta ou outros segredos sensíveis através dos logs da aplicação ao fornecer argumentos com tipos incorretos. Isso ocorre porque as funções públicas em `Plug.Crypto` utilizam guards no cabeçalho da função para validação de argumentos. Quando um guard falha, a VM Erlang levanta um `FunctionClauseError` que inclui os valores reais dos argumentos no frame superior da pilha. Como os blocos `rescue` da biblioteca e a função `Plug.Crypto.prune args from stacktrace/1` apenas lidam com exceções levantadas dentro do corpo de uma função, eles não capturam falhas de guard. Consequentemente, o Plug.Cowboy e o Bandit escrevem este frame no log de erros e o anexam como metadados de `crash reason`, que podem ser encaminhados para rastreadores de erros. Dois pontos de entrada principais são afetados: - `Plug.Crypto.verify/4` expõe a base da chave secreta quando o token não é nem um binário nem nulo. - `Plug.Crypto.secure compare/2` expõe o segredo do lado do servidor quando um operando não é um binário, como ocorre quando um cabeçalho de requisição ausente resulta em um valor nulo. O acesso às informações vazadas requer acesso separado aos logs da aplicação ou ao rastreador de erros.

Existe um problema onde a neutralização inadequada de entrada durante a geração de páginas web permite Cross-site Scripting (XSS) de mutação. Isso ocorre durante um ciclo de análise (parse) e serialização de HTML fornecido por um invasor. As funções `LazyHTML.to html/2` e `LazyHTML.Tree.to html/2` determinam se devem escapar o texto de um elemento baseando-se apenas no nome da tag. Consequentemente, um elemento `style` ou `script` dentro de conteúdo estrangeiro SVG ou MathML é analisado com referências de caracteres decodificadas, mas serializado como um elemento de texto bruto HTML, fazendo com que o texto seja emitido sem escape. Isso permite que marcações codificadas fechem o elemento ao serem reanalisadas e se tornem marcações ativas. Aplicações que analisam HTML não confiável, filtram o documento ou a árvore e, em seguida, o serializam para exibição são afetadas, pois a carga útil permanece como um nó de texto simples que ignora filtros de elementos ou atributos.

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.

A validação inadequada da quantidade especificada na entrada no stdlib permite que um invasor remoto degrade a disponibilidade ao fornecer uma URI cujo componente de porta seja uma sequência muito longa de dígitos. A função `uri string:get port/1` passa a substring da porta para `binary to integer/1` sem limite de comprimento. Consequentemente, uma porta sintaticamente válida de até aproximadamente 1,26 milhão de dígitos pode ser convertida com sucesso, consumindo centenas de milissegundos de aritmética de precisão arbitrária no processo solicitante. Essa conversão é alcançada por todos os caminhos de análise de autoridade em `uri string:parse/1`, incluindo as formas de host, nome registrado, IPv4 e IPv6. Qualquer aplicação que utilize `uri string:parse/1` para analisar URIs fornecidas por invasores está exposta.

A validação inadequada da quantidade especificada na entrada no módulo snmp permite que um invasor remoto degrade a disponibilidade. Um invasor pode enviar uma mensagem SNMP contendo um BER INTEGER cujo campo de comprimento seja arbitrariamente grande. A função `snmp pdus:dec integer notag/1` define seu limite de tamanho como infinito por padrão, e a função `do dec integer notag/2` acumula o valor em cada byte declarado com um deslocamento recursivo e um operador or bit a bit. O volume de trabalho cresce superlinearmente em relação ao comprimento declarado, pois cada operação atua sobre um bignum progressivamente maior. Embora exista uma variante com limite de tamanho `dec integer notag/2`, ela é acessada apenas por `dec snmp version/1`. Outros campos, como o identificador de requisição, status de erro, índice, campos de armadilha genéricos e específicos, boots e tempo do engine, e todos os valores de varbind decodificados por `dec value/1`, utilizam a forma ilimitada. A decodificação ocorre antes do processamento do PDU, portanto, nenhuma requisição válida é necessária para acionar o problema.

A validação inadequada da quantidade de entrada no módulo eldap permite que um servidor LDAP malicioso ou comprometido degrade a disponibilidade. O problema ocorre quando o servidor retorna uma URL de referência cujo componente de porta consiste em uma sequência excessivamente longa de dígitos. A função `parse port/2` passa a substring da porta para `list to integer/1` sem um limite de comprimento. Como a função de conversão aceita inteiros de qualquer tamanho, uma porta sintaticamente válida de até aproximadamente 1,26 milhão de dígitos pode ser processada, consumindo recursos significativos de CPU por meio de aritmética de precisão arbitrária. Esta falha é acionada quando uma aplicação passa uma referência fornecida pelo servidor para a função `parse ldap url/1`.

Um problema de recursão descontrolada na biblioteca padrão permite que um invasor que controle uma lista passada para as funções `inspect/1`, `List.to string/1` ou `List.to charlist/1` esgote a memória de um nó BEAM. O problema ocorre quando o prefixo imprimível de uma lista excede o `:printable limit` (4096 elementos por padrão), mas contém um elemento subsequente que não é um ponto de código válido, como um átomo ou um inteiro fora do intervalo. Isso faz com que a lista seja classificada incorretamente como uma charlist, resultando em um `ArgumentError`. Em `List.to string/1` e `List.to charlist/1`, a cláusula de resgate tenta construir uma mensagem de erro chamando `inspect(list)`, o que aciona novamente o mesmo caminho de erro. Como essa recursão não está em posição de cauda, a pilha do processo cresce até que o nó fique sem memória ou o processo seja encerrado pelo `max heap size`.

Um problema de Redirecionamento Aberto (Open Redirect) existe onde um invasor pode redirecionar o navegador de uma vítima para uma origem arbitrária. Isso ocorre porque a função `redirect/2` utiliza `validate local url!/2` para garantir que o destino seja um caminho local, mas falha ao não rejeitar caracteres de tabulação ASCII, LF ou CR. Como os navegadores removem esses caracteres antes de analisar a URL, um valor como `/<TAB>/example.com` ignora a validação e é interpretado como uma URL relativa ao esquema. A função `push patch/2` também é afetada em versões anteriores a 0.7.0. O problema é acionado quando a aplicação passa um valor influenciado externamente como o parâmetro `:to`, como um parâmetro `return to` durante o login ou um destino de navegação de um payload `handle event/3`.

Um problema de SQL Injection existe na biblioteca postgrex utilizada pelo elixir-ecto. A falha ocorre quando a opção `:comment` é utilizada na função `Postgrex.stream/4` ou na função `Ecto.Repo.stream/2`. Um invasor capaz de influenciar o valor da variável `:comment` pode usar a sequência `*/` para fechar o delimitador de comentário e anexar cláusulas SQL não autorizadas que são executadas com os privilégios da função da conexão. Isso acontece porque o software concatena o comentário no texto da instrução enviado na mensagem Parse sem escapar ou rejeitar a sequência `*/`, e a função `stream/4` não chama a função de validação `comment not present!/1` utilizada em outros pontos. A injeção é limitada à instrução transmitida, pois a mensagem Parse aceita apenas um único comando.

Um problema de Injeção de Comando de SO existe onde os comandos de configuração de implantação são gerados sem a devida filtragem de escape de shell dos valores de variáveis de ambiente. As funções `docker instructions/2` e `fly instructions/4` em `lib/livebook web/live/hub/teams/deployment group agent component.ex` interpolam esses valores, que são processados através de `online docker info/3`. Como os valores são colocados dentro de palavras de shell entre aspas duplas, um invasor com privilégios para definir variáveis de ambiente do grupo de implantação pode usar a substituição de comando (como `$(...)` ou crases) ou aspas duplas para injetar comandos arbitrários. Esses comandos são então executados na máquina local de qualquer usuário que copiar e executar as instruções de configuração geradas a partir da interface web. As instruções do Kubernetes não são afetadas, pois utilizam escape de manifesto YAML.

Um problema de Cross-Site Request Forgery (CSRF) ocorre quando o Livebook é configurado para usar o Livebook Teams para identidade. A função `handle request/4` em `lib/livebook/zta/livebook teams.ex` processa callbacks do tipo OAuth que contêm um marcador `teams identity` e um parâmetro `code`. Como a função `create auth request/1` em `lib/livebook/teams/requests.ex` não gera um estado ou nonce, o sistema não consegue verificar se o callback corresponde à sessão que iniciou o login. Um atacante na mesma organização do Livebook Teams pode iniciar um fluxo de login, capturar o código de autorização e induzir uma vítima a abrir uma URL contendo esse código. Isso faz com que a sessão da vítima seja vinculada à identidade do atacante. Consequentemente, qualquer trabalho, segredo ou dado produzido pela vítima é atribuído e acessível ao atacante, enquanto a vítima acredita estar usando sua própria conta.

Uma falha de segurança do tipo failing open no livebook permite que um cliente de rede não autenticado obtenha acesso total a um servidor que impõe a identidade por meio do Livebook Teams. Isso ocorre quando um Agente Livebook ou Servidor de Aplicativo armazena em cache um identificador de grupo de implantação que se torna irresolvível, como quando o grupo é excluído enquanto o agente está desconectado. A função `handle call/3` em `lib/livebook/hubs/team client.ex` não distingue entre um grupo irresolvível e um onde a imposição de identidade está desativada, levando o sistema a relatar que a imposição foi desligada. Consequentemente, a função `authenticate/3` em `lib/livebook/zta/livebook teams.ex` retorna metadados de identidade vazios, que o `build current user/3` no `LivebookWeb.UserPlug` mescla em um novo usuário com acesso total padrão. Este acesso é então concedido por `authorized?/1` no `LivebookWeb.AuthPlug`. Um invasor pode explorar isso para ler notebooks e segredos, executar código no runtime do servidor e interromper as operações.

Um erro de validação de origem permite que JavaScript de saída de notebook não confiável acione atalhos de teclado de toda a sessão. O recurso JS-view renderiza JavaScript em um iframe sandboxed de origem cruzada. No entanto, o shell do iframe em `iframe/priv/static/iframe/v5.html` encaminha eventos `keydown` para a página pai sem verificar `Event.isTrusted`. Consequentemente, eventos sintetizados via `window.dispatchEvent` são tratados como pressões de tecla genuínas. O relé em `assets/js/hooks/js view.js` redistribui esses eventos, que são então processados pelo manipulador de atalhos global em `assets/js/hooks/session.js` durante a fase de captura. Isso permite que scripts sandboxed executem atalhos em `LivebookWeb.SessionLive`, como forçar a avaliação de todas as células no notebook ou reiniciar o runtime, o que descarta o estado na memória. Um terceiro atalho pode excluir a célula focada. O impacto mais crítico é a avaliação completa forçada, que executa o código Elixir do notebook sem o consentimento do usuário. Isso pode ocorrer quando um usuário abre um notebook de terceiros ou de documentação publicada, e o efeito é espelhado para todos os colaboradores conectados.

Um problema de Relative Path Traversal permite que um invasor grave um arquivo com conteúdo controlado em um caminho arbitrário no sistema. Isso ocorre porque o caminho de importação em `Livebook.LiveMarkdown.Import.file entry metadata to attrs/1` recebe o nome da fonte do notebook literalmente, sem validação. Para entradas de arquivo do tipo URL, a função `Livebook.Session.file entry cache file/2` resolve o nome abaixo do diretório temporário da sessão sem verificar se o resultado permanece dentro desse diretório. Além disso, `Livebook.FileSystem.Utils.resolve unix like path/2` colapsa segmentos de diretórios pai, mas limita apenas na raiz do sistema de arquivos. Consequentemente, quando o conteúdo é solicitado e não existe cache, o sistema grava o corpo da resposta no caminho resolvido, criando diretórios pai conforme necessário. Isso permite que um invasor controle tanto o destino quanto o conteúdo do arquivo gravado em qualquer lugar onde o processo tenha permissões de gravação. Uma falta de verificação de contenção semelhante existe em `Livebook.Session.to attachment file entry/2`. Uma vítima aciona isso ao abrir um notebook fornecido por um invasor e fazer com que a entrada seja buscada dentro de sua sessão autenticada.

Um problema de cross-site scripting existe no phoenix live view devido à validação inadequada do esquema de URL. As funções `valid destination!/2` e `valid live navigation destination!/2` utilizam um auxiliar interno `uri scheme/1` que não detecta esquemas se a entrada começar com um espaço ou um caractere de controle ASCII. Como os navegadores padrão removem esses caracteres iniciais antes da análise, um invasor pode fornecer um payload como " javascript:alert(1)" que ignora a validação e é tratado como um caminho relativo seguro. Quando renderizado via `<.link href={...}>`, o navegador executa o script na sessão da vítima. Isso afeta aplicações que renderizam URLs fornecidas pelo usuário, como alvos de redirecionamento ou links de perfil.

Um problema no módulo `Postgrex.Notifications` permite que um invasor injete SQL na consulta de replay de reconexão ao influenciar o nome de um canal LISTEN. Embora a função `quote channel/1` sanitize aspas duplas, ela não escapa o delimitador de citação de cifrão `$$` usado no bloco de código anônimo dentro da função `handle connect/1`. Como a função `listen/3` apenas rejeita bytes nulos e nomes com mais de 63 bytes, um nome de canal contendo `$$` pode encerrar prematuramente a string delimitada por cifrões. Isso faz com que o PostgreSQL interprete o restante da entrada como instruções de nível superior, levando à rejeição da consulta de replay em cada tentativa de reconexão. Consequentemente, a conexão de notificação não consegue restabelecer as inscrições, resultando em uma negação de serviço onde as notificações são silenciosamente descartadas para todos os canais que compartilham essa conexão. Isso ocorre quando entradas não confiáveis são passadas como nome de canal para `Postgrex.Notifications.listen/3`.