Versión de OpenSSH 8.3 con corrección de vulnerabilidade scp

Despois de tres meses de desenvolvemento presentado liberación OpenSSH 8.3, unha implementación aberta de cliente e servidor para traballar a través dos protocolos SSH 2.0 e SFTP.

A nova versión engade protección contra ataques scp que permiten que o servidor pase outros nomes de ficheiro distintos dos solicitados (en oposición a vulnerabilidade pasada, o ataque non permite cambiar o directorio seleccionado polo usuario ou a máscara glob). Lembre que en SCP, o servidor decide que ficheiros e directorios enviar ao cliente, e o cliente só verifica a corrección dos nomes de obxectos devoltos. A esencia do problema identificado é que se falla a chamada do sistema utimes, entón o contido do ficheiro interprétase como metadatos do ficheiro.

Esta función, ao conectarse a un servidor controlado por un atacante, pódese usar para gardar outros nomes de ficheiros e outro contido no FS do usuario ao copiar usando scp en configuracións que provocan un fallo ao chamar a utimes (por exemplo, cando utimes está prohibido por utimes). a política de SELinux ou o filtro de chamadas ao sistema). Estímase que a probabilidade de ataques reais é mínima, xa que nas configuracións típicas a chamada de utimes non falla. Ademais, o ataque non pasa desapercibido: ao chamar a scp, móstrase un erro de transferencia de datos.

Cambios xerais:

  • En sftp, detívose o procesamento do argumento "-1", de xeito similar a ssh e scp, que anteriormente se aceptaban pero ignorados;
  • En sshd, ao usar IgnoreRhosts, agora hai tres opcións: "yes" - ignorar rhosts/shosts, "no" - respectar rhosts/shosts e "shosts-only" - permitir ".shosts" pero desactivar ".rhosts";
  • Ssh agora admite a substitución de %TOKEN nos axustes LocalFoward e RemoteForward usados ​​para redirixir sockets Unix;
  • Permitir cargar chaves públicas desde un ficheiro sen cifrar cunha chave privada se non hai un ficheiro separado coa chave pública;
  • Se libcrypto está dispoñible no sistema, ssh e sshd agora usan a implementación do algoritmo chacha20 desta biblioteca, en lugar da implementación portátil incorporada, que está atrasada no rendemento;
  • Implementouse a capacidade de volcar o contido dunha lista binaria de certificados revogados ao executar o comando "ssh-keygen -lQf /path";
  • A versión portátil implementa definicións de sistemas nos que os sinais coa opción SA_RESTART interrompen a operación de select;
  • Resolvéronse os problemas de construción en sistemas HP/UX e AIX;
  • Solucionáronse problemas coa construción de sandbox seccomp nalgunhas configuracións de Linux;
  • Mellorouse a detección da biblioteca libfido2 e resolveuse os problemas de compilación coa opción "--with-security-key-builtin".

Os desenvolvedores de OpenSSH tamén advertiron unha vez máis sobre a inminente descomposición de algoritmos que usan hash SHA-1 debido a promoción a eficacia dos ataques de colisión cun prefixo determinado (o custo de seleccionar unha colisión estímase en aproximadamente 45 mil dólares). Nun dos próximos lanzamentos, planean desactivar de forma predeterminada a posibilidade de usar o algoritmo de sinatura dixital de chave pública "ssh-rsa", que se menciona no RFC orixinal para o protocolo SSH e segue estendido na práctica (para probar o uso de ssh-rsa nos seus sistemas, pode tentar conectarse mediante ssh coa opción "-oHostKeyAlgorithms=-ssh-rsa").

Para suavizar a transición a novos algoritmos en OpenSSH, nunha versión futura habilitarase a configuración UpdateHostKeys de forma predeterminada, que migrará automaticamente os clientes a algoritmos máis fiables. Os algoritmos recomendados para a migración inclúen rsa-sha2-256/512 baseado en RFC8332 RSA SHA-2 (soportado desde OpenSSH 7.2 e usado por defecto), ssh-ed25519 (soportado desde OpenSSH 6.5) e ecdsa-sha2-nistp256/384 based en RFC521 ECDSA (soportado desde OpenSSH 5656).

Desde a última versión, "ssh-rsa" e "diffie-hellman-group14-sha1" foron eliminados da lista CASignatureAlgorithms que define os algoritmos que permiten asinar dixitalmente novos certificados, xa que o uso de SHA-1 nos certificados supón un risco adicional. debido a que o atacante ten tempo ilimitado para buscar unha colisión para un certificado existente, mentres que o tempo de ataque ás claves do host está limitado polo tempo de espera da conexión (LoginGraceTime).

Fonte: opennet.ru

Engadir un comentario