Eurico Nicacio

Uma falha no recurso de Registro Dinâmico de Clientes permite que um invasor com um token específico registre um aplicativo malicioso. Ao manipular a solicitação de registro, o invasor pode mapear os detalhes de seu próprio perfil para campos protegidos, como o ID do usuário `sub` ou a audiência pretendida `aud`. Isso permite a geração de tokens de segurança assinados que forjam informações de identidade, permitindo que o invasor se passe por outros usuários ou obtenha acesso não autorizado a serviços que dependem desses tokens para a verificação de identidade.

Um problema de escalonamento de privilégios existe no controle de acesso baseado em função do Rancher Manager. O campo `inheritedNamespacedRules` de um GlobalRole propaga permissões para namespaces nomeados de cada cluster downstream gerenciado pela instância do Rancher. Como este campo carece da validação de escalonamento de privilégios aplicada a outros campos de permissão de um GlobalRole, um usuário não administrativo poderia receber permissões em clusters downstream que excedem seus privilégios atuais por meio de uma vinculação de função global.

Um conflito de interpretação em `hackney url` permite Server Side Request Forgery (SSRF). Isso ocorre quando um host é fornecido como um literal IPv6 entre colchetes codificado em percentual ou um literal de IP com um ponto final. Enquanto uma lista de permissões (allowlist) do chamador usando `uri string:parse/1` e `inet:parse address/1` pode não reconhecer esses valores como endereços IP, o hackney ainda se conecta ao endereço indicado. O mesmo se aplica a alvos `Location` quando redirecionamentos são seguidos. O problema decorre do fato de `hackney url:normalize/2` passar valores decodificados para `inet parse:address/1` como estão, enquanto o caminho de conexão em `hackney happy:parse address/1` remove colchetes circundantes e o resolvedor ignora pontos finais, permitindo que essas formas ignorem o controle de literal de IP. Aplicações que utilizam uma lista de permissões de IP para evitar requisições a endereços internos, como loopback ou metadados de link-local, estão suscetíveis.

A falta de autorização na rota de download de recursos da unidade permite que um principal autenticado no controlador, como um agente de unidade ou um usuário com apenas permissão de login, leia recursos de charm de qualquer aplicativo em qualquer modelo. Isso pode ser feito por meio de uma requisição manipulada nomeando uma unidade arbitrária, expondo potencialmente dados sensíveis, como credenciais de registro de contêiner.

Um invasor remoto não autenticado pode definir `conn.host` e `conn.port` com valores que violam a gramática de host da RFC 3986, utilizando a autoridade de um alvo de solicitação HTTP/1 em forma absoluta ou de autoridade. Embora o software valide o cabeçalho `Host` e retorne um erro 400 se estiver malformado, a autoridade dentro do alvo da solicitação tem precedência, conforme exigido pela RFC 9112. A função `determine host and port!/4` em `lib/bandit/pipeline.ex` passa essa autoridade para a aplicação sem a devida validação. Isso permite a inserção de bytes NUL, DEL e não-ASCII, literais de IP inválidos e portas fora do intervalo 1..65535. Aplicações que constroem URLs absolutas usando `conn.host`, como através de `Plug.Conn.request url/1` ou auxiliares de URL do Phoenix, podem emitir links com uma autoridade escolhida pelo invasor. Para solicitações `CONNECT`, a string da porta não analisada é colocada em `conn.port`, o que pode fazer com que `Plug.Conn.request url/1` gere um erro, já que `Plug.Conn.port number/0` espera um número inteiro.

Formulários que utilizam elementos FileUpload ou ImageUpload com uma configuração personalizada de `saveToFileMount` armazenam arquivos enviados na pasta de armazenamento padrão `1:/user upload/` em vez do destino configurado. Isso pode fazer com que arquivos enviados terminem em um armazenamento publicamente acessível, mesmo que um armazenamento restrito e não público tenha sido configurado. Arquivos armazenados dessa forma são servidos diretamente, sem as verificações de acesso aplicadas a armazenamentos não públicos.

A função `quote()` emite um token `{ comment }` iniciando com `#`, que comenta o restante da linha do shell, incluindo as aspas de abertura de tokens de string subsequentes. Se uma string posterior contiver um terminador de linha (como ` `, `r`, `U+2028` ou `U+2029`), o comentário é encerrado e o restante da string é executado como entrada do shell. Além disso, a função `parse()` gera um token de comentário quando um caractere `#` aparece no meio de uma palavra. Isso pode causar problemas quando os chamadores combinam a saída de `parse()` com outras strings não confiáveis.

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.

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