Após cinco meses de desenvolvimento, foi lançado o OpenSSH 8.5, uma implementação aberta do cliente e servidor para operar nos protocolos SSH 2.0 e SFTP.
Os desenvolvedores do OpenSSH lembraram sobre a iminente mudança dos algoritmos que usam hashes SHA-1 para a categoria de obsoletos, devido ao aumento da eficácia dos ataques de colisão com prefixo fixo (o custo para encontrar uma colisão é estimado em cerca de 50 mil dólares). Em uma das próximas versões, planejam desativar por padrão a utilização do algoritmo de assinatura digital por chave pública 'ssh-rsa', que é mencionado no RFC original para o protocolo SSH e continua amplamente utilizado na prática.
Para verificar a aplicação do ssh-rsa em seus sistemas, você pode tentar se conectar via ssh com a opção '-oHostKeyAlgorithms=-ssh-rsa'. No entanto, a desativação por padrão das assinaturas digitais 'ssh-rsa' não significa uma rejeição completa do uso de chaves RSA, uma vez que, além do SHA-1, o protocolo SSH permite a utilização de outros algoritmos de hash. Em particular, além do 'ssh-rsa', continuará a ser possível utilizar os pares 'rsa-sha2-256' (RSA/SHA256) e 'rsa-sha2-512' (RSA/SHA512).
Para suavizar a transição para os novos algoritmos, o OpenSSH 8.5 inclui por padrão a configuração UpdateHostKeys, que permite atualizar automaticamente os clientes para algoritmos mais seguros. Com essa configuração ativada, é habilitada uma extensão especial do protocolo 'hostkeys@openssh.com', que permite que o servidor informe o cliente sobre todas as chaves de host disponíveis após a autenticação. O cliente pode refletir essas chaves em seu arquivo ~/.ssh/known_hosts, facilitando a atualização das chaves de host e simplificando a troca de chaves. servidor.
O uso do UpdateHostKeys é limitado por algumas ressalvas, que podem ser revogadas no futuro: a chave deve ser mencionada no UserKnownHostsFile e não ser utilizada no GlobalKnownHostsFile; a chave deve estar presente apenas sob um nome; não deve ser utilizado um certificado de chave de host; no known_hosts não devem ser utilizadas máscaras por nome de host; a configuração VerifyHostKeyDNS deve estar desativada; e o parâmetro UserKnownHostsFile deve estar ativo.
Entre os algoritmos recomendados para migração estão rsa-sha2-256/512 com base na RFC8332 RSA SHA-2 (suportado a partir do OpenSSH 7.2 e utilizado por padrão), ssh-ed25519 (suportado a partir do OpenSSH 6.5) e ecdsa-sha2-nistp256/384/521 com base na RFC5656 ECDSA (suportado a partir do OpenSSH 5.7).
Outras mudanças:
- Mudanças relacionadas à segurança:
- No ssh-agent, uma vulnerabilidade causada pela liberação repetida de uma área de memória já liberada (double-free) foi corrigida. O problema se manifestou a partir do lançamento do OpenSSH 8.2 e pode ser potencialmente explorado se um atacante tiver acesso ao socket ssh-agent no sistema local. A exploração é dificultada pelo fato de que somente root e o usuário original têm acesso ao socket. O cenário de ataque mais provável é redirecionar o agente para uma conta sob controle do invasor, ou para um host no qual o invasor tenha acesso root.
- No sshd, foi adicionada proteção contra a transmissão de parâmetros muito grandes com o nome de usuário para o subsistema PAM, o que permite bloquear vulnerabilidades nos módulos PAM (Pluggable Authentication Module). Por exemplo, a mudança evita que o sshd seja utilizado como vetor para explorar uma vulnerabilidade de root recentemente descoberta no Solaris (CVE-2020-14871).
- Mudanças que podem interromper a compatibilidade:
- No ssh e sshd, foi reformulado um método experimental de troca de chaves resistente a ataques de computadores quânticos. Computadores quânticos resolvem radicalmente mais rápido o problema de fatoração de números naturais, que é a base dos atuais algoritmos de criptografia assimétrica e que é efetivamente insolúvel em processadores clássicos. O método utilizado baseia-se no algoritmo NTRU Prime, desenvolvido para cripto-sistemas pós-quânticos, e no método de troca de chaves baseado em curvas elípticas X25519. Em vez de sntrup4591761x25519-sha512@tinyssh.org, o método agora é identificado como sntrup761x25519-sha512@openssh.com (o algoritmo sntrup4591761 foi substituído por sntrup761).
- No ssh e sshd, a ordem de anúncio dos algoritmos de assinatura digital foi alterada. Agora, ED25519 é oferecido primeiro, em vez de ECDSA.
- No ssh e sshd, a configuração dos parâmetros de qualidade de serviço TOS/DSCP para sessões interativas agora é realizada antes da configuração da conexão TCP.
- No ssh e sshd, o suporte para o cifrador rijndael-cbc@lysator.liu.se foi descontinuado, que é idêntico ao aes256-cbc e foi utilizado até a aprovação da RFC-4253.
- Por padrão, a função CheckHostIP está desativada, sua utilidade é mínima, mas seu uso torna a rotação de chaves para hosts por trás de balanceadores de carga significativamente mais complicada.
- No sshd, foram adicionadas as configurações PerSourceMaxStartups e PerSourceNetBlockSize para limitar a intensidade de inicialização dos manipuladores com base no endereço do cliente. Esses parâmetros permitem um controle mais detalhado sobre as restrições na inicialização de processos, em comparação com a configuração geral MaxStartups.
- No ssh e sshd, foi adicionada a nova configuração LogVerbose, que permite forçar a elevação do nível de informações de depuração registradas, com a possibilidade de filtragem por padrões, funções e arquivos.
- No ssh, ao aceitar uma nova chave de host, são exibidos todos os nomes dos hosts e endereços IP, associados à chave.
- No ssh, agora é permitido especificar a opção UserKnownHostsFile=none para desativar o uso do arquivo known_hosts na identificação das chaves de host.
- No ssh_config para ssh, foi adicionada a configuração KnownHostsCommand, que permite obter os dados de known_hosts a partir da saída de um comando especificado.
- No ssh_config para ssh, foi adicionada a opção PermitRemoteOpen, que permite restringir o ponto de destino ao usar a opção RemoteForward com SOCKS.
- No ssh, para chaves FIDO, é garantido um novo pedido de PIN em caso de falha na operação de assinatura digital devido a um PIN incorreto e ausência de solicitação de PIN do usuário (por exemplo, quando não foi possível obter dados biométricos corretos e o dispositivo voltou ao modo de entrada manual do PIN).
- No sshd, o mecanismo de isolamento de processo baseado em seccomp-bpf na plataforma Linux agora suporta chamadas de sistema adicionais.
- A utilidade contrib/ssh-copy-id foi atualizada.
Fonte: opennet.ru
