Após seis meses de desenvolvimento, foi apresentado o lançamento do OpenSSH 8.9, uma implementação aberta de cliente e servidor para trabalhar nos protocolos SSH 2.0 e SFTP. A nova versão do sshd corrige uma vulnerabilidade que poderia permitir acesso não autenticado. O problema é causado por um estouro de número inteiro no código de autenticação, mas só pode ser explorado em combinação com outros erros lógicos no código.
Na sua forma atual, a vulnerabilidade não pode ser explorada quando o modo de separação de privilégios está ativado, uma vez que a 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 está habilitado por padrão desde 2002 desde 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 da versão 6.5 (2014), a vulnerabilidade é bloqueada pela compilação com a inclusão de sinalizadores de proteção contra estouro de número inteiro.
Outras mudanças:
- A versão portátil do OpenSSH em sshd removeu o suporte nativo para hash de senhas usando o algoritmo MD5 (permitindo o retorno da vinculação com bibliotecas externas, como libxcrypt).
- ssh, sshd, ssh-add e ssh-agent implementam um subsistema para restringir o encaminhamento e o 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 só pode ser usada para autenticar qualquer usuário conectado 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 através de um host intermediário scylla.example.org, você pode usar o seguinte comando: $ ssh-add -h "[email protegido]» \ -h «scylla.example.org» \ -h «scylla.example.org>[email protegido]» \ ~/.ssh/id_ed25519
- Em ssh e sshd, um algoritmo híbrido foi adicionado por padrão à lista KexAlgorithms, que determina a ordem em que os métodos de troca de chaves são selecionados.[email protegido]"(ECDH/x25519 + NTRU Prime), resistente à seleção em computadores quânticos. No OpenSSH 8.9, este método de negociação foi adicionado entre os métodos ECDH e DH, mas está planejado para ser habilitado por padrão na próxima versão.
- ssh-keygen, ssh e ssh-agent melhoraram o manuseio de chaves de token FIDO usadas para verificação de dispositivos, incluindo chaves para autenticação biométrica.
- Adicionado o comando "ssh-keygen -Y match-principals" ao ssh-keygen para verificar nomes de usuário no arquivo permitidonamelist.
- ssh-add e ssh-agent fornecem a capacidade de adicionar chaves FIDO protegidas por um código PIN ao ssh-agent (a solicitação do PIN é exibida no momento da autenticação).
- ssh-keygen permite a escolha do algoritmo de hash (sha512 ou sha256) durante a geração da assinatura.
- No ssh e no sshd, para melhorar o desempenho, os dados da rede são lidos diretamente no buffer dos pacotes recebidos, ignorando o buffer intermediário na pilha. A colocação direta dos dados recebidos em um buffer de canal é implementada de maneira semelhante.
- No ssh, a diretiva PubkeyAuthentication expandiu a lista de parâmetros suportados (yes|no|unbound|host-bound) para fornecer a capacidade de selecionar a extensão de protocolo a ser usada.
Em uma versão futura, planejamos alterar o padrão do utilitário scp para usar SFTP em vez do protocolo legado SCP/RCP. O SFTP usa métodos de tratamento de nomes mais previsíveis e não usa processamento shell de padrões glob em nomes de arquivos no 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, e o cliente apenas verifica a exatidão dos nomes dos objetos retornados, o que, na ausência de verificações adequadas por parte do cliente, permite o servidor para transferir outros nomes de arquivos diferentes daqueles solicitados. O protocolo SFTP não apresenta esses problemas, mas não suporta a expansão de caminhos especiais como “~/”. Para resolver essa diferença, a versão anterior do OpenSSH introduziu uma nova extensão de protocolo SFTP para os caminhos ~/ e ~user/ na implementação do servidor SFTP.
Fonte: opennet.ru