Después de seis meses de desarrollo, se presentó el lanzamiento de OpenSSH 8.9, una implementación abierta de cliente y servidor para trabajar sobre los protocolos SSH 2.0 y SFTP. La nueva versión de sshd corrige una vulnerabilidad que potencialmente podría permitir el acceso no autenticado. El problema se debe a un desbordamiento de enteros en el código de autenticación, pero sólo puede explotarse en combinación con otros errores lógicos en el código.
En su forma actual, la vulnerabilidad no se puede explotar cuando el modo de separación de privilegios está habilitado, ya que su manifestación se bloquea mediante comprobaciones independientes realizadas en el código de seguimiento de separación de privilegios. El modo de separación de privilegios está habilitado de forma predeterminada desde 2002 desde OpenSSH 3.2.2 y ha sido obligatorio desde el lanzamiento de OpenSSH 7.5 publicado en 2017. Además, en las versiones portátiles de OpenSSH a partir de la versión 6.5 (2014), la vulnerabilidad se bloquea mediante la compilación con la inclusión de indicadores de protección de desbordamiento de enteros.
Otros cambios:
- La versión portátil de OpenSSH en sshd ha eliminado el soporte nativo para hash de contraseñas utilizando el algoritmo MD5 (lo que permite volver a vincularse con bibliotecas externas como libxcrypt).
- ssh, sshd, ssh-add y ssh-agent implementan un subsistema para restringir el reenvío y el uso de claves agregadas a ssh-agent. El subsistema le permite establecer reglas que determinan cómo y dónde se pueden usar las claves en ssh-agent. Por ejemplo, para agregar una clave que solo se puede usar para autenticar a cualquier usuario que se conecte al host scylla.example.org, el usuario perseus al host cetus.example.org y el usuario medea al host charybdis.example.org. con la redirección a través de un host intermedio scylla.example.org, puedes usar el siguiente comando: $ ssh-add -h "[email protected]» \ -h «scylla.example.org» \ -h «scylla.example.org>[email protected]» \ ~/.ssh/id_ed25519
- En ssh y sshd, se ha agregado un algoritmo híbrido de forma predeterminada a la lista KexAlgorithms, que determina el orden en el que se seleccionan los métodos de intercambio de claves.[email protected]"(ECDH/x25519 + NTRU Prime), resistente a la selección en computadoras cuánticas. En OpenSSH 8.9, este método de negociación se agregó entre los métodos ECDH y DH, pero está previsto que se habilite de forma predeterminada en la próxima versión.
- ssh-keygen, ssh y ssh-agent han mejorado el manejo de las claves token FIDO utilizadas para la verificación de dispositivos, incluidas las claves para la autenticación biométrica.
- Se agregó el comando "ssh-keygen -Y match-principals" a ssh-keygen para verificar los nombres de usuario en el archivo de lista de nombres permitidos.
- ssh-add y ssh-agent brindan la posibilidad de agregar claves FIDO protegidas por un código PIN a ssh-agent (la solicitud de PIN se muestra en el momento de la autenticación).
- ssh-keygen permite elegir el algoritmo hash (sha512 o sha256) durante la generación de firmas.
- En ssh y sshd, para mejorar el rendimiento, los datos de la red se leen directamente en el búfer de paquetes entrantes, sin pasar por el búfer intermedio en la pila. De manera similar se implementa la colocación directa de los datos recibidos en un buffer de canal.
- En ssh, la directiva PubkeyAuthentication ha ampliado la lista de parámetros admitidos (sí|no|unbound|host-bound) para brindar la capacidad de seleccionar la extensión de protocolo a usar.
En una versión futura, planeamos cambiar la configuración predeterminada de la utilidad scp para usar SFTP en lugar del protocolo SCP/RCP heredado. SFTP utiliza métodos de manejo de nombres más predecibles y no utiliza procesamiento de shell de patrones globales en nombres de archivos en el otro lado del host, lo que crea problemas de seguridad. En particular, cuando se utiliza SCP y RCP, el servidor decide qué archivos y directorios enviar al cliente, y el cliente sólo comprueba la exactitud de los nombres de los objetos devueltos, lo que, en ausencia de comprobaciones adecuadas por parte del cliente, permite que servidor para transferir otros nombres de archivos diferentes a los solicitados. El protocolo SFTP no tiene estos problemas, pero no admite la expansión de rutas especiales como “~/”. Para abordar esta diferencia, la versión anterior de OpenSSH introdujo una nueva extensión del protocolo SFTP para las rutas ~/ y ~user/ en la implementación del servidor SFTP.
Fuente: opennet.ru