Michał Wąsowski

A alocação de recursos sem limites na validação do caminho do certificado do módulo public key permite que um atacante remoto não autenticado cause a negação de serviço. Ao enviar uma cadeia de certificados X.509 manipulada durante o handshake TLS, um atacante pode desencadear o crescimento ilimitado da árvore de políticas de certificado durante o processamento de políticas RFC 5280 na função `pkix path validation/3`. Isso ocorre porque as funções `pubkey policy tree:add leaves/2` e `pubkey policy tree:add leaf siblings/2` estendem a árvore por política por certificado, levando a um crescimento exponencial. Isso pode travar os escalonadores BEAM e esgotar a memória do nó, resultando no travamento completo da máquina virtual. O problema afeta qualquer conexão TLS de entrada ou saída que valide a cadeia do peer, como clientes SSL/TLS e servidores mutual-TLS.

Uma discrepância de resposta observável no módulo `ssh sftpd` permite que um usuário SFTP autenticado enumere arquivos e diretórios fora do diretório raiz configurado. O manipulador `SSH FXP REALPATH` chama `relate file name/3` com `Canonicalize=false`, o que permite que componentes de travessia de caminho ignorem a verificação `is within root/2`. O caminho então entra em `resolve symlinks/2`, que executa chamadas de sistema `read link()` em caminhos arbitrários do sistema de arquivos. Um invasor pode usar um caminho de travessia manipulado em uma solicitação REALPATH para criar um oráculo de existência de caminho, pois o servidor retorna `SSH FXP NAME` se o caminho existir e `SSH FX NO SUCH FILE` caso contrário. Este problema está associado ao arquivo `lib/ssh/src/ssh sftpd.erl` e à função `ssh sftpd:handle op/4`. Esta falha apenas vaza a existência de caminhos e não fornece acesso ao conteúdo de arquivos ou credenciais.

Um loop infinito existe no módulo `ssh sftpd` do Erlang OTP. Um usuário SFTP autenticado pode tornar um canal SFTP permanentemente inoperante ao enviar `SSH MSG CHANNEL EXTENDED DATA` com um código de tipo diferente de zero, um buffer pendente vazio e um payload dentro do limite de tamanho de pacote SFTP. Isso dispara um loop recursivo de cauda na função `handle data()`, fazendo com que o processo pare de processar mensagens e leve ao crescimento ilimitado da memória da fila de mensagens e alto consumo de CPU. O impacto é a negação de serviço nos canais SFTP visados. Esse efeito pode ser amplificado se a configuração `max channels` estiver definida como infinita, permitindo que um único usuário abra canais ilimitados.

Um canal lateral de temporização na autenticação de senha permite que atacantes remotos não autenticados enumerem nomes de usuário. Quando o daemon SSH é configurado com a opção `user passwords` ou `password`, a função `check password/3()` no módulo `ssh auth` realiza um cálculo PBKDF2-SHA256 para nomes de usuário válidos, levando aproximadamente 300ms. Por outro lado, para nomes de usuário inválidos, a função `get password option/2()` no módulo `ssh options` retorna imediatamente. Essa discrepância permite que um atacante distinga entre nomes de usuário válidos e inválidos em uma única tentativa.

Um problema no módulo `ssh sftpd` permite a descoberta de arquivos através da exposição de informações sensíveis. O manipulador `SSH FXP READLINK` envia o resultado bruto da função `file:read link/2` para o cliente sem utilizar `chroot filename/2` para remover o prefixo da raiz do backend. Consequentemente, um cliente SFTP autenticado pode criar um link simbólico dentro do chroot apontando para `/`, e a leitura desse link via `SSH FXP READLINK` retorna o caminho absoluto da raiz do backend (ex: `/data/sftp`) em vez do valor chrooted `/`. Isso expõe o caminho absoluto do sistema de arquivos do diretório raiz do SFTP e de quaisquer alvos de links simbólicos dentro dele, embora o conteúdo de arquivos, credenciais e caminhos fora do diretório raiz permaneçam inacessíveis. Este problema está associado ao arquivo `lib/ssh/src/ssh sftpd.erl` e requer que o subsistema SFTP esteja habilitado com a opção `root` configurada na chamada `ssh sftpd:subsystem spec/1`.

Uma falha de path traversal no módulo `ssh sftpd` do Erlang OTP ssh permite que um usuário SFTP autenticado modifique atributos de arquivos fora do diretório chroot configurado. O daemon SFTP armazena o caminho bruto fornecido pelo usuário em handles de arquivo em vez do caminho resolvido pelo chroot. Quando o `SSH FXP FSETSTAT` é emitido em tal handle, os atributos do arquivo (permissões, propriedade, timestamps) são modificados no caminho real do sistema de arquivos, ignorando completamente o limite do diretório raiz. Isso requer que o servidor esteja configurado com a opção root e que o arquivo alvo exista no sistema de arquivos real no mesmo caminho relativo. Esta falha permite apenas a modificação de atributos de arquivos; o conteúdo dos arquivos não pode ser lido ou alterado. Se o daemon SSH for executado como root, um invasor pode obter escalonamento de privilégios ao definir o bit setuid em binários, alterar a propriedade de arquivos sensíveis ou tornar configurações do sistema graváveis por qualquer usuário. O problema está associado ao arquivo `lib/ssh/src/ssh sftpd.erl` e às funções `ssh sftpd:do open/4` e `ssh sftpd:handle op/4`.

An improper limitation of a pathname to a restricted directory, specifically a 'Path Traversal' issue, exists in the Erlang OTP `ssh sftpd` module. The SFTP server uses string prefix matching with the `lists:prefix/2` function instead of proper path component validation when verifying if a path is within the configured root directory. This allows authenticated users to access sibling directories that share a common name prefix with the configured root directory. For example, if the root directory is set to `/home/user1`, paths like `/home/user10` or `/home/user1 backup` could be incorrectly considered within the root. The issue is associated with the program file `lib/ssh/src/ssh sftpd.erl` and the `ssh sftpd:is within root/2` function.

An issue exists in Erlang OTP ssh (ssh transport modules) that allows for Denial of Service via Resource Depletion. The SSH transport layer, by default, advertises legacy zlib compression and inflates attacker-controlled payloads without a size limit before authentication. This enables a reliable memory exhaustion attack. Two compression algorithms are affected: zlib, which activates immediately after key exchange, and zlib@openssh.com, which activates post-authentication. Each SSH packet can decompress approximately 255 MB from 256 KB of data, resulting in a 1029:1 amplification ratio. Multiple packets can quickly exhaust available memory, potentially causing Out-Of-Memory (OOM) kills in environments with limited memory. The issue is associated with the `ssh transport.erl` file and the `ssh transport:decompress/2` and `ssh transport:handle packet part/4` routines.