Lanzamiento de OpenSSH 8.5

Después de cinco meses de desarrollo, se presenta el lanzamiento de OpenSSH 8.5, una implementación abierta del cliente y servidor para trabajar con los protocolos SSH 2.0 y SFTP.

Los desarrolladores de OpenSSH recordaron la próxima clasificación de algoritmos obsoletos que utilizan hashes SHA-1, debido a la creciente eficacia de los ataques de colisión con prefijo dado (el costo de obtener una colisión se estima en aproximadamente 50 mil dólares). En una de las próximas versiones, se planea desactivar por defecto la posibilidad de usar el algoritmo de firma digital con clave pública 'ssh-rsa', que se menciona en el RFC original para el protocolo SSH y sigue siendo ampliamente utilizado en la práctica.

Para verificar el uso de ssh-rsa en sus sistemas, puede intentar conectarse por ssh con la opción '-oHostKeyAlgorithms=-ssh-rsa'. Sin embargo, desactivar por defecto las firmas digitales 'ssh-rsa' no significa un rechazo total del uso de claves RSA, ya que, además de SHA-1, el protocolo SSH permite el uso de otros algoritmos de hash. En particular, además de 'ssh-rsa', se quedará la posibilidad de usar las combinaciones 'rsa-sha2-256' (RSA/SHA256) y 'rsa-sha2-512' (RSA/SHA512).

Para suavizar la transición a nuevos algoritmos, OpenSSH 8.5 incluye por defecto la configuración UpdateHostKeys, que permite automáticamente migrar a los clientes a algoritmos más seguros. Con esta configuración se activa una extensión especial del protocolo 'hostkeys@openssh.com', que permite al servidor informar al cliente, tras la autenticación, sobre todas las claves de host disponibles. El cliente puede reflejar estas claves en su archivo ~/ .ssh/known_hosts, lo que facilita la actualización de claves de host y simplifica el cambio de claves. servidor.

El uso de UpdateHostKeys está limitado por varias condiciones, las cuales podrían ser eliminadas en el futuro: la clave debe mencionarse en UserKnownHostsFile y no usarse en GlobalKnownHostsFile; la clave debe estar presente solo bajo un nombre; no se debe aplicar un certificado de clave de host; no se deben usar comodines por nombre de host en known_hosts; debe estar desactivada la configuración VerifyHostKeyDNS; debe estar activo el parámetro UserKnownHostsFile.

Entre los algoritmos recomendados para migrar se mencionan rsa-sha2-256/512 basado en RFC8332 RSA SHA-2 (compatible desde OpenSSH 7.2 y utilizado por defecto), ssh-ed25519 (compatible desde OpenSSH 6.5) y ecdsa-sha2-nistp256/384/521 basado en RFC5656 ECDSA (compatible desde OpenSSH 5.7).

Otros cambios:

• Cambios relacionados con la seguridad:
  • Se ha corregido una vulnerabilidad en ssh-agent provocada por la liberación repetida de un bloque de memoria ya liberado (double-free). El problema se manifiesta desde el lanzamiento de OpenSSH 8.2 y puede ser explotado si el atacante tiene acceso al socket de ssh-agent en el sistema local. La explotación se complica por el hecho de que solo el usuario root y el usuario original tienen acceso al socket. El escenario de ataque más probable es redirigir el agente a una cuenta controlada por el atacante, o a un host en el que el atacante tenga acceso root.
  • Se ha agregado protección en sshd contra la transmisión de parámetros muy grandes con el nombre de usuario al subsistema PAM, lo que permite bloquear vulnerabilidades en los módulos del sistema PAM (Pluggable Authentication Module). Por ejemplo, el cambio permite evitar que sshd se utilice como vector para aprovechar una vulnerabilidad de root recientemente descubierta en Solaris (CVE-2020-14871).
• Cambios que potencialmente afectan la compatibilidad:
  • En ssh y sshd se ha mejorado el método experimental de intercambio de claves, resistente a ataques de ordenadores cuánticos. Los ordenadores cuánticos son radicalmente más rápidos para resolver la factorización de números naturales en factores primos, que es la base de los algoritmos de cifrado asimétrico modernos y es eficazmente no resoluble en procesadores clásicos. El método utilizado se basa en el algoritmo NTRU Prime, desarrollado para criptosistemas postcuánticos, y en el método de intercambio de claves basado en curvas elípticas X25519. En lugar de sntrup4591761x25519-sha512@tinyssh.org, el método ahora se identifica como sntrup761x25519-sha512@openssh.com (el algoritmo sntrup4591761 ha sido reemplazado por sntrup761).
  • En ssh y sshd se ha cambiado el orden de anuncio de los algoritmos de firma digital soportados. Ahora se ofrece ED25519 primero en lugar de ECDSA.
  • En ssh y sshd, la configuración de los parámetros de calidad de servicio TOS/DSCP para sesiones interactivas ahora se realiza antes de establecer la conexión TCP.
  • En ssh y sshd se ha dejado de soportar el cifrado rijndael-cbc@lysator.liu.se, que es idéntico a aes256-cbc y se utilizó hasta la aprobación del RFC-4253.
  • Por defecto, se ha desactivado el parámetro CheckHostIP, cuyo beneficio es insignificante, pero su uso complica significativamente la rotación de claves para hosts detrás de equilibradores de carga.
• En sshd se han añadido configuraciones PerSourceMaxStartups y PerSourceNetBlockSize para limitar la intensidad de inicio de los manejadores en función de la dirección del cliente. Los parámetros especificados permiten gestionar más finamente la restricción sobre el inicio de procesos, en comparación con la configuración general MaxStartups.
• En ssh y sshd se ha añadido una nueva configuración LogVerbose, que permite elevar forzosamente el nivel de información de depuración registrada en el log, con la posibilidad de filtrado por patrones, funciones y archivos.
• En ssh, al aceptar una nueva clave de host se asegura la visualización de todos los nombres de host y direcciones IP, asociados con la clave.
• En ssh se permite especificar la opción UserKnownHostsFile=none para desactivar el uso del archivo known_hosts al identificar las claves de host.
• En ssh_config para ssh se ha añadido la configuración KnownHostsCommand, que permite obtener datos de known_hosts a partir de la salida del comando especificado.
• En ssh_config para ssh se ha añadido la opción PermitRemoteOpen, que permite restringir el destino al utilizar la opción RemoteForward con SOCKS.
• En ssh, para las llaves FIDO se asegura una nueva solicitud de PIN en caso de fallo de la operación de firma digital debido a un PIN incorrecto y la falta de solicitud de PIN al usuario (por ejemplo, cuando no se pudieron obtener datos biométricos correctos y el dispositivo volvió a la entrada manual del PIN).
• En sshd, se ha añadido soporte para llamadas al sistema adicionales en el mecanismo de aislamiento de procesos basado en seccomp-bpf en la plataforma Linux.
• Se ha actualizado la utilidad contrib/ssh-copy-id.

Fuente: opennet.ru