Zach Daniel

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 invasor não autenticado pode injetar uma expressão de filtro usando um cursor de paginação de keyset forjado. Isso ocorre porque as ações de leitura com paginação de keyset decodificam os cursores `page[:after]` ou `page[:before]` fornecidos pelo cliente na função `decode values/2` em `lib/ash/page/keyset.ex` usando `non executable binary to term/2` com `[:safe]`. Embora esse guard bloqueie novos átomos, funs e portas, ele não bloqueia structs construídas a partir de átomos já internados em uma aplicação em execução. Consequentemente, uma expressão `%Ash.Query.Call{}` decodificada pode ser inserida no filtro de keyset como um valor de comparação em `do filters/4` e avaliada. Como o cursor ignora a macro `Ash.Expr`, o runtime não aplica o gate `private?/public?`. O impacto varia de acordo com a camada de dados: o AshPostgres permite a injeção de SQL, enquanto as camadas de dados ETS e Simple permitem que a expressão seja avaliada no processo como uma chamada de função arbitrária.

Um problema de consumo descontrolado de recursos existe onde um invasor pode esgotar a memória do nó usando um cursor de paginação de keyset manipulado. Ações de leitura que utilizam paginação de keyset desserializam cursores fornecidos pelo cliente através da função `decode values/2` em `lib/ash/page/keyset.ex`. Este processo decodifica o valor em base64 e o passa para `:erlang.binary to term/2` sem limitação de tamanho. Como o formato de termo externo do Erlang suporta cargas úteis compactadas com zlib, o decodificador pode inflar um cursor pequeno em dezenas de megabytes de memória heap. Como o software apenas codifica cursores como não compactados, o decodificador aceita formas de termos que o codificador não produz. Múltiplas requisições simultâneas podem agregar essas alocações e causar a terminação do nó. Isso envolve as variáveis `page[:after]` e `page[:before]`.

A Neutralização Imprópria de Elementos Especiais na Lógica de Consulta de Dados permite que um invasor forje um relacionamento com um registro que não consegue nomear e recupere o valor secreto usado para a pesquisa. Isso ocorre quando `manage relationship` é usado com `on lookup: :relate` em um relacionamento `belongs to`, pois o valor de pesquisa fornecido pelo cliente é passado para `Ash.Query.filter/2` sem ser convertido para o tipo de atributo. Consequentemente, um mapa aninhado enviado em vez de um escalar é interpretado como um predicado de filtro em vez de um literal, transformando a pesquisa de um registro específico em uma consulta por qualquer registro que corresponda a uma condição. Além disso, a omissão de `Ash.Query.limit(1)` permite que `Ash.read one/2` distinga entre nenhuma correspondência, uma correspondência e várias correspondências, criando um oráculo para o valor de pesquisa. A autorização não é afetada, pois a política de leitura de destino ainda se aplica.

Existe um problema onde usuários podem definir o valor de um argumento de ação privado destinado a ser controlado exclusivamente por código confiável do lado do servidor. Argumentos de ação declarados com `public?: false` são destinados a configurações internas, como aquelas via `Ash.Changeset.set private argument/3`, e não devem ser definíveis por meio de entrada do usuário final. No entanto, a filtragem desses argumentos privados é incompleta quando um changeset é construído a partir de um mapa de parâmetros. Em caminhos de changeset regulares (`for create`, `for update`, `for destroy`), os argumentos privados são removidos apenas se a chave do parâmetro for um átomo; se a chave for um binário (string), o que é comum para parâmetros fornecidos pelo usuário, o argumento é mantido. No caminho atômico (`Ash.Changeset.fully atomic changeset/4`, incluindo atualizações atômicas e em massa), os argumentos privados não são removidos, independentemente do tipo de chave. Isso permite que um invasor injete valores em argumentos privados, podendo levar à escalada de privilégios ou violações de integridade, especialmente se argumentos como `acting user id` forem usados para autorização ou propriedade de registros.

Existe uma falha de autorização incorreta no ash, potencialmente permitindo o bypass de autenticação. O problema está associado ao arquivo `lib/ash/policy/policy.ex` e à função `Elixir.Ash.Policy.Policy`:expression/2.

Existe uma falha de autorização incorreta no ash-project ash, permitindo o bypass de autenticação. O problema está associado aos arquivos do programa `lib/ash/policy/authorizer/authorizer.ex` e à rotina `Elixir.Ash.Policy.Authorizer`:strict filters/2.

Existe uma vulnerabilidade de autorização incorreta no ash, permitindo a exploração de níveis de segurança de controle de acesso configurados incorretamente. Este problema está associado aos arquivos do programa `lib/ash/actions/create/bulk.ex`, `lib/ash/actions/destroy/bulk.ex`, `lib/ash/actions/update/bulk.ex`, e às rotinas do programa `Elixir.Ash.Actions.Create.Bulk`:run/5, `Elixir.Ash.Actions.Destroy.Bulk`:run/6, e `Elixir.Ash.Actions.Update.Bulk:run`/6.

The issue affects the ash authentication phoenix library, where session tokens remain valid on the server after a user logs out. This creates a security gap where compromised tokens can continue to work, even after the user logs out. The sessions stored in the database still expire, limiting the duration during which this could be exploited. Users cannot fully invalidate their sessions when logging out from shared or potentially compromised devices. However, changing one's password does invalidate all other sessions. This may cause compliance issues with security frameworks requiring complete session invalidation.