Después de seis meses de desarrollo, se presenta la versión OpenSSH 8.9, una implementación abierta del cliente y servidor para trabajar con los protocolos SSH 2.0 y SFTP. En esta nueva versión se ha corregido una vulnerabilidad en sshd que podría permitir el acceso sin autenticación. El problema se debe a un desbordamiento de enteros en el código de autenticación, pero su explotación solo es posible en combinación con otros errores lógicos en el código.
En su estado actual, la vulnerabilidad no es explotable al activar el modo de separación de privilegios, ya que su manifestación es bloqueada por verificaciones específicas realizadas en el código de seguimiento de separación de privilegios. Este modo se activó de forma predeterminada en 2002, comenzando con OpenSSH 3.2.2, y es obligatorio desde el lanzamiento de OpenSSH 7.5, publicado en 2017. Además, en las versiones portables de OpenSSH a partir de la versión 6.5 (2014), la vulnerabilidad es bloqueada al compilar con las banderas de protección contra desbordamientos de enteros.
Otros cambios:
- En la versión portable de OpenSSH se ha eliminado el soporte integrado para el hash de contraseñas utilizando el algoritmo MD5 (se permite la vinculación con bibliotecas externas como libxcrypt).
- En ssh, sshd, ssh-add y ssh-agent se ha implementado un subsistema para restringir el reenvío y uso de claves añadidas al ssh-agent. Este subsistema permite establecer reglas que determinan cómo y dónde se pueden usar las claves en el ssh-agent. Por ejemplo, para añadir una clave que solo pueda usarse para autenticarse al conectar cualquier usuario al host scylla.example.org, al usuario perseus al host cetus.example.org y al usuario medea al host charybdis.example.org con redirección a través del host intermedio scylla.example.org, se puede utilizar el siguiente comando: $ ssh-add -h "perseus@cetus.example.org" \ -h "scylla.example.org" \ -h "scylla.example.org>medea@charybdis.example.org" \ ~\/ .ssh\/id_ed25519
- En ssh y sshd, se ha añadido de forma predeterminada el algoritmo híbrido «sntrup761x25519-sha512@openssh.com» (ECDH/x25519 + NTRU Prime) a la lista de KexAlgorithms, que define el orden de selección de los métodos de intercambio de claves, resistente a ataques de computadoras cuánticas. En la versión OpenSSH 8.9, este método de negociación se ha añadido entre los métodos ECDH y DH, pero se planea utilizarlo de forma predeterminada en la próxima versión.
- En ssh-keygen, ssh y ssh-agent se ha mejorado el manejo de las claves de los tokens FIDO utilizados para la verificación del dispositivo, incluidas las claves para la autenticación biométrica.
- En ssh-keygen se ha añadido el comando «ssh-keygen -Y match-principals» para verificar los nombres de usuario en el archivo de lista de nombres permitidos.
- En ssh-add y ssh-agent se ha brindado la posibilidad de añadir claves FIDO protegidas por PIN al ssh-agent (se solicita el PIN en el momento de la autenticación).
- En ssh-keygen se permite seleccionar el algoritmo de hash (sha512 o sha256) al momento de generar la firma.
- En ssh y sshd, para mejorar el rendimiento, se asegura la lectura de datos de red directamente en el búfer de paquetes entrantes, omitiendo el almacenamiento intermedio en la pila. Similarmente, se ha implementado la colocación directa de los datos recibidos en el búfer de canal.
- En ssh, en la directiva PubkeyAuthentication se ha ampliado la lista de parámetros soportados (yes|no|unbound|host-bound) para ofrecer la opción de seleccionar la variante de extensión de protocolo a utilizar.
En una de las siguientes versiones, se planea cambiar por defecto la utilidad scp para usar SFTP en lugar del obsoleto protocolo SCP/RCP. En SFTP se utilizan métodos de manejo más predecibles de los nombres y no se emplea el procesamiento de patrones glob en los nombres de archivos a través del shell en el otro host, lo que crea problemas de seguridad. En particular, al usar SCP y RCP, el servidor decide qué archivos y directorios se envían al cliente, y el cliente solo verifica la validez de los nombres de los objetos devueltos, lo que, en ausencia de las debidas comprobaciones del lado del cliente, permite servidor que se transfieran otros nombres de archivos diferentes a los solicitados. El protocolo SFTP carece de los problemas mencionados, pero no admite la expansión de rutas especiales como «~/». Para resolver esta diferencia, en la última versión de OpenSSH se propuso una nueva extensión del protocolo SFTP para la expansión de las rutas ~/ y ~user/.
Fuente: opennet.ru
