După șase luni de dezvoltare, a fost prezentată lansarea OpenSSH 8.9, o implementare deschisă de client și server pentru lucrul peste protocoalele SSH 2.0 și SFTP. Noua versiune de sshd remediază o vulnerabilitate care ar putea permite accesul neautentificat. Problema este cauzată de o depășire a numărului întreg în codul de autentificare, dar poate fi exploatată numai în combinație cu alte erori logice din cod.
În forma sa actuală, vulnerabilitatea nu poate fi exploatată atunci când modul de separare a privilegiilor este activat, deoarece manifestarea ei este blocată prin verificări separate efectuate în codul de urmărire a separării privilegiilor. Modul de separare a privilegiilor a fost activat implicit din 2002 de la OpenSSH 3.2.2 și a fost obligatoriu de la lansarea OpenSSH 7.5, publicată în 2017. În plus, în versiunile portabile ale OpenSSH care încep cu versiunea 6.5 (2014), vulnerabilitatea este blocată prin compilare cu includerea semnalizatoarelor de protecție a depășirii întregi.
Alte modificari:
- Versiunea portabilă a OpenSSH în sshd a eliminat suportul nativ pentru hashing parolele folosind algoritmul MD5 (permițând întoarcerea legăturii cu biblioteci externe, cum ar fi libxcrypt).
- ssh, sshd, ssh-add și ssh-agent implementează un subsistem pentru a restricționa redirecționarea și utilizarea cheilor adăugate la ssh-agent. Subsistemul vă permite să setați reguli care determină cum și unde pot fi utilizate cheile în ssh-agent. De exemplu, pentru a adăuga o cheie care poate fi folosită doar pentru a autentifica orice utilizator care se conectează la gazda scylla.example.org, utilizatorul perseus la gazda cetus.example.org și utilizatorul medea la gazda charybdis.example.org cu redirecționare printr-o gazdă intermediară scylla.example.org, puteți utiliza următoarea comandă: $ ssh-add -h "[e-mail protejat]" \ -h "scylla.example.org" \ -h "scylla.example.org>[e-mail protejat]\ ~/.ssh/id_ed25519
- În ssh și sshd, un algoritm hibrid a fost adăugat în mod implicit la lista KexAlgorithms, care determină ordinea în care sunt selectate metodele de schimb de chei.[e-mail protejat]„(ECDH/x25519 + NTRU Prime), rezistent la selecție pe computere cuantice. În OpenSSH 8.9, această metodă de negociere a fost adăugată între metodele ECDH și DH, dar este planificat să fie activată implicit în următoarea ediție.
- ssh-keygen, ssh și ssh-agent au o gestionare îmbunătățită a cheilor de simbol FIDO utilizate pentru verificarea dispozitivului, inclusiv cheile pentru autentificare biometrică.
- S-a adăugat comanda „ssh-keygen -Y match-principals” la ssh-keygen pentru a verifica numele de utilizator în fișierul listele de nume permise.
- ssh-add și ssh-agent oferă posibilitatea de a adăuga chei FIDO protejate printr-un cod PIN la ssh-agent (solicitarea PIN este afișată în momentul autentificării).
- ssh-keygen permite alegerea algoritmului de hashing (sha512 sau sha256) în timpul generării semnăturii.
- În ssh și sshd, pentru a îmbunătăți performanța, datele de rețea sunt citite direct în buffer-ul pachetelor de intrare, ocolind tamponarea intermediară de pe stivă. Plasarea directă a datelor primite într-un buffer de canal este implementată într-un mod similar.
- În ssh, directiva PubkeyAuthentication a extins lista de parametri acceptați (da|nu|nelegat|legat la gazdă) pentru a oferi posibilitatea de a selecta extensia de protocol de utilizat.
Într-o versiune viitoare, intenționăm să schimbăm valoarea implicită a utilitarului scp pentru a utiliza SFTP în loc de protocolul SCP/RCP vechi. SFTP folosește metode mai previzibile de gestionare a numelor și nu utilizează procesarea shell a modelelor glob în numele fișierelor din partea celeilalte gazde, ceea ce creează probleme de securitate. În special, atunci când se utilizează SCP și RCP, serverul decide ce fișiere și directoare să trimită clientului, iar clientul verifică doar corectitudinea numelor obiectelor returnate, ceea ce, în absența verificărilor adecvate din partea clientului, permite server pentru a transfera alte nume de fișiere care diferă de cele solicitate. Protocolul SFTP nu are aceste probleme, dar nu acceptă extinderea căilor speciale precum „~/”. Pentru a rezolva această diferență, versiunea anterioară a OpenSSH a introdus o nouă extensie de protocol SFTP la căile ~/ și ~user/ în implementarea serverului SFTP.
Sursa: opennet.ru