Versão OpenSSH 8.3 com correção de vulnerabilidade scp

Após três meses de desenvolvimento apresentado liberar OpenSSH 8.3, uma implementação aberta de cliente e servidor para trabalhar através dos protocolos SSH 2.0 e SFTP.

A nova versão adiciona proteção contra ataques scp que permitem ao servidor passar outros nomes de arquivos além dos solicitados (em oposição a vulnerabilidade passada, o ataque não possibilita a alteração do diretório selecionado pelo usuário ou da máscara glob). Lembre-se de que no SCP o servidor decide quais arquivos e diretórios enviar ao cliente, e o cliente apenas verifica a exatidão dos nomes dos objetos retornados. A essência do problema identificado é que, se a chamada do sistema utimes falhar, o conteúdo do arquivo será interpretado como metadados do arquivo.

Este recurso, ao se conectar a um servidor controlado por um invasor, pode ser usado para salvar outros nomes de arquivos e outros conteúdos no FS do usuário ao copiar usando scp em configurações que levam à falha ao chamar utimes (por exemplo, quando utimes é proibido por a política SELinux ou filtro de chamada do sistema). A probabilidade de ataques reais é estimada como mínima, já que em configurações típicas a chamada utimes não falha. Além disso, o ataque não passa despercebido - ao chamar o scp, é mostrado um erro de transferência de dados.

Alterações gerais:

• No sftp, o processamento do argumento “-1” foi interrompido, semelhante ao ssh e scp, que foi anteriormente aceito, mas ignorado;
• No sshd, ao usar IgnoreRhosts, agora existem três opções: "yes" - ignorar rhosts/shosts, "no" - respeitar rhosts/shosts e "shosts-only" - permitir ".shosts" mas desabilitar ".rhosts";
• Ssh agora suporta substituição de %TOKEN nas configurações LocalFoward e RemoteForward usadas para redirecionar soquetes Unix;
• Permitir o carregamento de chaves públicas de um arquivo não criptografado com chave privada se não houver um arquivo separado com a chave pública;
• Se libcrypto estiver disponível no sistema, ssh e sshd agora usam a implementação do algoritmo chacha20 desta biblioteca, em vez da implementação portátil integrada, que fica para trás em desempenho;
• Implementada a capacidade de despejar o conteúdo de uma lista binária de certificados revogados ao executar o comando “ssh-keygen -lQf /path”;
• A versão portátil implementa definições de sistemas em que sinais com a opção SA_RESTART interrompem a operação de seleção;
• Resolvidos problemas de montagem em sistemas HP/UX e AIX;
• Corrigidos problemas com a construção do sandbox seccomp em algumas configurações do Linux;
• Detecção aprimorada da biblioteca libfido2 e problemas de compilação resolvidos com a opção "--with-security-key-builtin".

Os desenvolvedores do OpenSSH também alertaram mais uma vez sobre a decomposição iminente de algoritmos usando hashes SHA-1 devido a promoção a eficácia dos ataques de colisão com um determinado prefixo (o custo de seleção de uma colisão é estimado em aproximadamente 45 mil dólares). Em um dos próximos lançamentos, eles planejam desabilitar por padrão a capacidade de usar o algoritmo de assinatura digital de chave pública “ssh-rsa”, que é mencionado na RFC original para o protocolo SSH e continua difundido na prática (para testar o uso de ssh-rsa em seus sistemas, você pode tentar conectar via ssh com a opção “-oHostKeyAlgorithms=-ssh-rsa”).

Para facilitar a transição para novos algoritmos no OpenSSH, em uma versão futura a configuração UpdateHostKeys será habilitada por padrão, o que migrará automaticamente os clientes para algoritmos mais confiáveis. Os algoritmos recomendados para migração incluem rsa-sha2-256/512 baseado em RFC8332 RSA SHA-2 (suportado desde OpenSSH 7.2 e usado por padrão), ssh-ed25519 (suportado desde OpenSSH 6.5) e ecdsa-sha2-nistp256/384/521 baseado no RFC5656 ECDSA (suportado desde OpenSSH 5.7).

A partir da última versão, "ssh-rsa" e "diffie-hellman-group14-sha1" foram removidos da lista CASignatureAlgorithms que define os algoritmos permitidos para assinar digitalmente novos certificados, uma vez que o uso de SHA-1 em certificados representa um risco adicional devido a isso o invasor tem tempo ilimitado para procurar uma colisão para um certificado existente, enquanto o tempo de ataque às chaves do host é limitado pelo tempo limite de conexão (LoginGraceTime).

Fonte: opennet.ru