După șase luni de dezvoltare, a fost lansată versiunea OpenSSH 8.9, o implementare deschisă a clientului și serverului pentru a lucra prin protocoalele SSH 2.0 și SFTP. În noua versiune, în sshd a fost eliminată o vulnerabilitate care ar putea permite accesul fără autentificare. Problema este cauzată de o suprascriere a întregilor numere în codul de autentificare, dar exploatarea este posibilă doar în combinație cu alte erori logice în cod.
În forma actuală, vulnerabilitatea nu este exploatabilă atunci când este activat modul de separare a privilegiilor, deoarece manifestarea ei este blocată de verificările distincte efectuate în codul de urmărire a separării privilegiilor. Modul de separare a privilegiilor a fost activat implicit în 2002, începând cu OpenSSH 3.2.2, și este obligatoriu începând cu versiunea OpenSSH 7.5, publicată în 2017. În plus, în versiuni portabile de OpenSSH începând cu versiunea 6.5 (2014), vulnerabilitatea este blocată prin compilarea cu activarea flag-urilor de protecție împotriva suprascrierilor întregilor numere.
Paleta de culori a fost modificată, oferind o separare mai contrastantă între text și fundal.
- În versiunea portabilă de OpenSSH, sshd a eliminat suportul încorporat pentru hashing-ul parolelor folosind algoritmul MD5 (pentru returnare este permisă legarea cu biblioteci externe, cum ar fi libxcrypt).
- În ssh, sshd, ssh-add și ssh-agent a fost implementat un subsistem pentru a restricționa retransmisia și utilizarea cheilor adăugate în ssh-agent. Subsistemul permite stabilirea unor reguli care definesc cum și unde pot fi folosite cheile în ssh-agent. De exemplu, pentru a adăuga o cheie care poate fi utilizată doar pentru autentificare la conectarea oricărui utilizator la gazda scylla.example.org, utilizatorul perseus la gazda cetus.example.org și utilizatorul medea la gazda charybdis.example.org cu redirecționare prin gazda intermediară scylla.example.org, se poate folosi comanda următoare: $ ssh-add -h «perseus@cetus.example.org» \ -h «scylla.example.org» \ -h «scylla.example.org>medea@charybdis.example.org» \ ~\/ .ssh\/ id_ed25519
- În ssh și sshd, în lista KexAlgorithms, care determină ordinea de alegere a metodelor de schimb de chei, a fost adăugat implicit algoritmul hibrid „sntrup761x25519-sha512@openssh.com” (ECDH/x25519 + NTRU Prime), rezistent la atacurile computațional-quantice. În versiunea OpenSSH 8.9, această metodă de negociere a fost adăugată între metodele ECDH și DH, dar în următoarea versiune se preconizează că va fi utilizată implicit.
- În ssh-keygen, ssh și ssh-agent a fost îmbunătățită gestionarea cheilor FIDO, utilizate pentru verificarea dispozitivului, inclusiv chei pentru autentificarea biometrică.
- În ssh-keygen a fost adăugată comanda „ssh-keygen -Y match-principals” pentru a verifica numele utilizatorilor din fișierul cu lista de nume permise.
- În ssh-add și ssh-agent a fost adăugată posibilitatea de a adăuga chei FIDO protejate cu PIN în ssh-agent (solicitarea PIN-ului este afişată în momentul autentificării).
- În ssh-keygen a fost permisă selectarea algoritmului de hash (sha512 sau sha256) în timpul generării semnăturii.
- În ssh și sshd, pentru a îmbunătăți performanța, s-a asigurat citirea datelor de rețea direct în bufferul pachetelor de intrare, ocolind buffering-ul intermediar din stivă. În mod similar, a fost implementată plasarea directă a datelor primite în bufferul canalului.
- În ssh, în direcția PubkeyAuthentication a fost extinsă lista de parametri acceptați (yes|no|unbound|host-bound) pentru a oferi posibilitatea de a alege opțiunea de extensie a protocolului utilizată.
În una dintre următoarele versiuni, se preconizează ca utilitarul scp să fie mutat în mod implicit la utilizarea SFTP în locul protocolului SCP/RCP învechit. SFTP folosește metode mai previzibile de gestionare a numelui și nu are o procesare glob a șabloanelor de nume de fișiere prin shell pe partea celeilalte gazde, care creează probleme de securitate. În special, în cazul SCP și RCP, serverul decide ce fișiere și directoare să trimită clientului, iar clientul doar verifică corectitudinea numelui obiectelor returnate, ceea ce în cazul lipsei unor verificări adecvate pe partea clientului permite server transmiterea altor nume de fișiere, diferite de cele solicitate. Protocolul SFTP nu are problemele menționate, dar nu suportă dezvăluirea căilor speciale, cum ar fi „~/”. Pentru a elimina această diferență, în ultima versiune OpenSSH a fost propusă o nouă extensie a protocolului SFTP pentru a dezvălui căile ~/ și ~user/.
Sursa: opennet.ro
