Após seis meses de desenvolvimento, foi lançado o OpenSSH 8.9, uma implementação aberta do cliente e servidor para trabalhar com os protocolos SSH 2.0 e SFTP. Na nova versão, uma vulnerabilidade no sshd foi corrigida, potencialmente permitindo o acesso sem autenticação. O problema foi causado por um estouro de inteiro no código de autenticação, mas sua exploração é possível apenas em combinação com outros erros lógicos no código.
No estado atual, a vulnerabilidade não é explorável quando o modo de separação de privilégios está ativado, pois sua manifestação é bloqueada por verificações separadas realizadas no código de rastreamento de separação de privilégios. O modo de separação de privilégios foi ativado por padrão em 2002, começando com o OpenSSH 3.2.2, e é obrigatório desde o lançamento do OpenSSH 7.5, publicado em 2017. Além disso, nas versões portáteis do OpenSSH a partir do lançamento 6.5 (2014), a vulnerabilidade é bloqueada pela compilação com a inclusão de flags de proteção contra estouros de inteiros.
Outras mudanças:
- Na versão portátil do OpenSSH, o suporte interno para hash de senhas usando o algoritmo MD5 foi removido (para retorno é permitida a associação com bibliotecas externas, como libxcrypt).
- No ssh, sshd, ssh-add e ssh-agent, foi implementado um subsistema para limitar o redirecionamento e uso de chaves adicionadas ao ssh-agent. O subsistema permite definir regras que determinam como e onde as chaves podem ser usadas no ssh-agent. Por exemplo, para adicionar uma chave que pode ser usada apenas para autenticação ao conectar qualquer usuário ao host scylla.example.org, o usuário perseus ao host cetus.example.org e o usuário medea ao host charybdis.example.org com redirecionamento pelo host intermediário scylla.example.org, pode-se usar o seguinte comando: $ ssh-add -h "perseus@cetus.example.org" \ -h "scylla.example.org" \ -h "scylla.example.org>medea@charybdis.example.org" \ ~\/ssh\/id_ed25519
- No ssh e sshd, um algoritmo híbrido "sntrup761x25519-sha512@openssh.com" (ECDH/x25519 + NTRU Prime), resistente a ataques de computadores quânticos, foi adicionado por padrão à lista KexAlgorithms, que define a ordem de seleção dos métodos de troca de chaves. Na versão OpenSSH 8.9, este método de negociação foi incluído entre os métodos ECDH e DH, mas está previsto para ser ativado por padrão na próxima versão.
- No ssh-keygen, ssh e ssh-agent melhoraram o manuseio das chaves de tokens FIDO utilizados para verificar dispositivos, incluindo chaves para autenticação biométrica.
- No ssh-keygen foi adicionando o comando 'ssh-keygen -Y match-principals' para verificar nomes de usuários no arquivo da lista de nomes permitidos.
- No ssh-add e ssh-agent foi fornecida a capacidade de adicionar chaves FIDO protegidas por PIN ao ssh-agent (a solicitação de PIN é exibida durante a autenticação).
- No ssh-keygen foi permitido escolher o algoritmo de hash (sha512 ou sha256) durante a formação da assinatura.
- No ssh e sshd, para melhorar o desempenho, foi implementada a leitura de dados de rede diretamente no buffer de pacotes recebidos, evitando o armazenamento intermediário na pilha. Da mesma forma, foi implementada a transferência direta dos dados recebidos para o buffer do canal.
- No ssh, a diretiva PubkeyAuthentication teve sua lista de parâmetros suportados expandida (yes|no|unbound|host-bound) para permitir a escolha da variante do protocolo utilizada.
Em uma das próximas versões, está planejada a mudança padrão do utilitário scp para o uso de SFTP, em vez do protocolo obsoleto SCP/RCP. O SFTP adota métodos de manuseio de nomes mais previsíveis e não utiliza a manipulação de glob nos nomes de arquivos no lado do outro host, o que cria problemas de segurança. Em particular, ao usar SCP e RCP, o servidor decide quais arquivos e diretórios enviar ao cliente, enquanto o cliente apenas verifica a validade dos nomes de objetos retornados, permitindo a transmissão de outros nomes de arquivos diferentes dos solicitados na ausência de verificações apropriadas. servidor O protocolo SFTP não possui esses problemas, mas não suporta a expansão de caminhos especiais, como '~/'. Para resolver essa diferença, na versão anterior do OpenSSH foi proposto uma nova extensão do protocolo SFTP para a expansão dos caminhos ~/ e ~user/.
Fonte: opennet.ru
