Despois de seis meses de desenvolvemento, presentouse o lanzamento de OpenSSH 8.9, unha implementación aberta de cliente e servidor para traballar sobre os protocolos SSH 2.0 e SFTP. A nova versión de sshd soluciona unha vulnerabilidade que podería permitir o acceso sen autenticación. O problema é causado por un desbordamento de números enteiros no código de autenticación, pero só se pode explotar en combinación con outros erros lóxicos no código.
Na súa forma actual, a vulnerabilidade non se pode explotar cando o modo de separación de privilexios está activado, xa que a súa manifestación está bloqueada mediante comprobacións separadas realizadas no código de seguimento de separación de privilexios. O modo de separación de privilexios estivo activado de forma predeterminada desde 2002 desde OpenSSH 3.2.2, e é obrigatorio desde o lanzamento de OpenSSH 7.5 publicado en 2017. Ademais, nas versións portátiles de OpenSSH que comezan coa versión 6.5 (2014), a vulnerabilidade está bloqueada pola compilación coa inclusión de bandeiras de protección de desbordamento de números enteiros.
Outros cambios:
- A versión portátil de OpenSSH en sshd eliminou a compatibilidade nativa para hash contrasinais mediante o algoritmo MD5 (permitindo que se devolva a ligazón con bibliotecas externas como libxcrypt).
- ssh, sshd, ssh-add e ssh-agent implementan un subsistema para restrinxir o reenvío e o uso das chaves engadidas a ssh-agent. O subsistema permítelle establecer regras que determinan como e onde se poden usar as chaves en ssh-agent. Por exemplo, para engadir unha clave que só se pode usar para autenticar calquera usuario que se conecte ao host scylla.example.org, o usuario perseus ao host cetus.example.org e o usuario medea ao host charybdis.example.org con redirección a través dun host intermedio scylla.example.org, pode usar o seguinte comando: $ ssh-add -h "[protexido por correo electrónico]" \ -h "scylla.example.org" \ -h "scylla.example.org>[protexido por correo electrónico]\ ~/.ssh/id_ed25519
- En ssh e sshd, engadiuse un algoritmo híbrido por defecto á lista de KexAlgorithms, que determina a orde na que se seleccionan os métodos de intercambio de claves.[protexido por correo electrónico]"(ECDH/x25519 + NTRU Prime), resistente á selección en ordenadores cuánticos. En OpenSSH 8.9, este método de negociación engadiuse entre os métodos ECDH e DH, pero está previsto que se active por defecto na próxima versión.
- ssh-keygen, ssh e ssh-agent melloraron o manexo das claves de token FIDO utilizadas para a verificación do dispositivo, incluídas as claves para a autenticación biométrica.
- Engadiuse o comando "ssh-keygen -Y match-principals" a ssh-keygen para comprobar os nomes de usuario no ficheiro da lista de nomes permitidos.
- ssh-add e ssh-agent ofrecen a posibilidade de engadir claves FIDO protexidas por un código PIN a ssh-agent (a solicitude de PIN móstrase no momento da autenticación).
- ssh-keygen permite a elección do algoritmo de hash (sha512 ou sha256) durante a xeración de sinaturas.
- En ssh e sshd, para mellorar o rendemento, os datos da rede lense directamente no búfer dos paquetes entrantes, evitando o búfer intermedio da pila. A colocación directa dos datos recibidos nun búfer de canle implícase dun xeito similar.
- En ssh, a directiva PubkeyAuthentication ampliou a lista de parámetros admitidos (yes|no|unbound|host-bound) para proporcionar a posibilidade de seleccionar a extensión de protocolo que se vai utilizar.
Nunha versión futura, pensamos cambiar o valor predeterminado da utilidade scp para utilizar SFTP en lugar do protocolo SCP/RCP herdado. SFTP usa métodos de manexo de nomes máis previsibles e non usa o procesamento de shell de patróns glob en nomes de ficheiros do outro host, o que crea problemas de seguridade. En particular, ao usar SCP e RCP, o servidor decide que ficheiros e directorios enviar ao cliente, e o cliente só verifica a corrección dos nomes de obxectos devoltos, o que, a falta de verificacións adecuadas no lado do cliente, permite o servidor para transferir outros nomes de ficheiro que difiran dos solicitados. O protocolo SFTP non ten estes problemas, pero non admite a expansión de camiños especiais como "~/". Para solucionar esta diferenza, a versión anterior de OpenSSH introduciu unha nova extensión de protocolo SFTP para as rutas ~/ e ~user/ na implementación do servidor SFTP.
Fonte: opennet.ru