Després de sis mesos de desenvolupament, es va presentar el llançament d'OpenSSH 8.9, una implementació oberta de client i servidor per treballar amb els protocols SSH 2.0 i SFTP. La nova versió de sshd soluciona una vulnerabilitat que podria permetre un accés no autenticat. El problema és causat per un desbordament de nombres enters al codi d'autenticació, però només es pot explotar en combinació amb altres errors lògics del codi.
En la seva forma actual, la vulnerabilitat no es pot explotar quan el mode de separació de privilegis està habilitat, ja que la seva manifestació està bloquejada per comprovacions separades realitzades al codi de seguiment de separació de privilegis. El mode de separació de privilegis s'ha habilitat per defecte des de l'any 2002 des de l'OpenSSH 3.2.2, i és obligatori des del llançament d'OpenSSH 7.5 publicat el 2017. A més, a les versions portàtils d'OpenSSH a partir de la versió 6.5 (2014), la vulnerabilitat es bloqueja mitjançant la compilació amb la inclusió de senyals de protecció de desbordament d'enters.
Altres canvis:
- La versió portàtil d'OpenSSH a sshd ha eliminat el suport natiu per a les contrasenyes hash mitjançant l'algoritme MD5 (permet que torni l'enllaç amb biblioteques externes com libxcrypt).
- ssh, sshd, ssh-add i ssh-agent implementen un subsistema per restringir el reenviament i l'ús de claus afegides a ssh-agent. El subsistema us permet establir regles que determinen com i on es poden utilitzar les claus a ssh-agent. Per exemple, per afegir una clau que només es pot utilitzar per autenticar qualsevol usuari que es connecti a l'amfitrió scylla.example.org, l'usuari perseus a l'amfitrió cetus.example.org i l'usuari medea a l'amfitrió charybdis.example.org amb la redirecció mitjançant un host intermedi scylla.example.org, podeu utilitzar l'ordre següent: $ ssh-add -h "[protegit per correu electrònic]" \ -h "scylla.example.org" \ -h "scylla.example.org>[protegit per correu electrònic]\ ~/.ssh/id_ed25519
- En ssh i sshd, s'ha afegit un algorisme híbrid per defecte a la llista KexAlgorithms, que determina l'ordre en què es seleccionen els mètodes d'intercanvi de claus.[protegit per correu electrònic]"(ECDH/x25519 + NTRU Prime), resistent a la selecció en ordinadors quàntics. A l'OpenSSH 8.9, aquest mètode de negociació es va afegir entre els mètodes ECDH i DH, però està previst que s'habiliten de manera predeterminada en la propera versió.
- ssh-keygen, ssh i ssh-agent han millorat la gestió de les claus de testimoni FIDO utilitzades per a la verificació del dispositiu, incloses les claus per a l'autenticació biomètrica.
- S'ha afegit l'ordre "ssh-keygen -Y match-principals" a ssh-keygen per comprovar els noms d'usuari al fitxer de llista de noms permès.
- ssh-add i ssh-agent ofereixen la possibilitat d'afegir claus FIDO protegides per un codi PIN a ssh-agent (la sol·licitud de PIN es mostra en el moment de l'autenticació).
- ssh-keygen permet escollir l'algorisme hash (sha512 o sha256) durant la generació de signatura.
- En ssh i sshd, per millorar el rendiment, les dades de xarxa es llegeixen directament a la memòria intermèdia dels paquets entrants, evitant la memòria intermèdia de la pila. La col·locació directa de les dades rebudes en un buffer de canal s'implementa de manera similar.
- En ssh, la directiva PubkeyAuthentication ha ampliat la llista de paràmetres admesos (sí|no|unbound|host-bound) per oferir la possibilitat de seleccionar l'extensió de protocol que cal utilitzar.
En una versió futura, tenim previst canviar el valor predeterminat de la utilitat scp per utilitzar SFTP en comptes del protocol SCP/RCP heretat. SFTP utilitza mètodes de gestió de noms més predictibles i no utilitza el processament de l'intèrpret d'ordres dels patrons glob en els noms de fitxers de l'altre amfitrió, cosa que crea problemes de seguretat. En particular, quan s'utilitza SCP i RCP, el servidor decideix quins fitxers i directoris enviar al client, i el client només comprova la correcció dels noms d'objectes retornats, cosa que, en absència de comprovacions adequades al costat del client, permet servidor per transferir altres noms de fitxer que difereixen dels sol·licitats. El protocol SFTP no té aquests problemes, però no admet l'expansió de camins especials com ara "~/". Per solucionar aquesta diferència, la versió anterior d'OpenSSH va introduir una nova extensió de protocol SFTP als camins ~/ i ~user/ a la implementació del servidor SFTP.
Font: opennet.ru