Lansarea OpenSSH 8.5

După cinci luni de dezvoltare, a fost lansată versiunea OpenSSH 8.5, o implementare deschisă a clientului și serverului pentru a funcționa conform protocoalelor SSH 2.0 și SFTP.

Dezvoltatorii OpenSSH au reamintit despre tranziția iminentă a algoritmilor care folosesc hash-uri SHA-1 în categoria algoritmilor învechiți, din cauza creșterii eficienței atacurilor de coliziune cu un prefix dat (costul generării unei coliziuni se estimează la aproximativ 50.000 de dolari). În una dintre viitoarele versiuni, se preconizează dezactivarea, în mod implicit, a utilizării algoritmului de semnare digitală cu cheie publică „ssh-rsa”, care este menționat în RFC-ul original pentru protocolul SSH și rămâne foarte răspândit în practică.

Pentru a verifica utilizarea ssh-rsa în sistemele dvs., puteți încerca să vă conectați prin ssh cu opțiunea '-oHostKeyAlgorithms=-ssh-rsa'. De asemenea, dezactivarea implicită a semnăturilor digitale 'ssh-rsa' nu înseamnă o renunțare completă la utilizarea cheilor RSA, deoarece, pe lângă SHA-1, protocolul SSH permite utilizarea altor algoritmi de calcul al hash-urilor. În special, vor rămâne opțiuni pentru combinațiile 'rsa-sha2-256' (RSA/SHA256) și 'rsa-sha2-512' (RSA/SHA512).

Pentru a facilita tranziția la noile algoritmi, OpenSSH 8.5 include, în mod implicit, setarea UpdateHostKeys, care permite clienților să fie automat mutați la algoritmi mai siguri. Prin această setare, este activat o extensie specială a protocolului „hostkeys@openssh.com”, care permite serverului, după finalizarea autentificării, să informeze clientul despre toate cheile disponibile ale gazdelor. Clientul poate reflecta aceste chei în fișierul său ~/.ssh/known_hosts, ceea ce permite actualizarea cheilor gazdelor și simplifică schimbarea cheilor. server.

Utilizarea UpdateHostKeys este restricționată de câteva excepții care pot fi anulate în viitor: cheia trebuie menționată în UserKnownHostsFile și nu trebuie utilizată în GlobalKnownHostsFile; cheia trebuie să fie prezentă doar sub un singur nume; nu trebuie folosit un certificat de cheie a gazdei; nu trebuie utilizate măști de nume de gazdă în known_hosts; setarea VerifyHostKeyDNS trebuie dezactivată; parametrul UserKnownHostsFile trebuie să fie activat.

Printre algoritmii recomandați pentru migrare se numără rsa-sha2-256/512 bazat pe RFC8332 RSA SHA-2 (suportat din OpenSSH 7.2 și utilizat implicit), ssh-ed25519 (suportat din OpenSSH 6.5) și ecdsa-sha2-nistp256/384/521 bazat pe RFC5656 ECDSA (suportat din OpenSSH 5.7).

Paleta de culori a fost modificată, oferind o separare mai contrastantă între text și fundal.

• Modificări legate de securitate:
  • În ssh-agent a fost corectată o vulnerabilitate cauzată de eliberarea repetată a unei zone de memorie deja eliberate (double-free). Problema apare începând cu versiunea OpenSSH 8.2 și poate fi exploatată în condițiile în care atacatorul are acces la socket-ul ssh-agent de pe sistemul local. Exploatarea este complicată de faptul că acces la socket au doar utilizatorul root și utilizatorul original. Cel mai probabil scenariu de atac implică redirecționarea agentului către un cont controlat de atacator sau către un gazdă pe care atacatorul o controlează cu acces root.
  • În sshd a fost adăugată o protecție împotriva transmiterii unor parametri foarte mari cu numele de utilizator în subsistemul PAM, ceea ce permite blocarea vulnerabilităților în modulele sistemului PAM (Pluggable Authentication Module). De exemplu, modificarea permite prevenirea utilizării sshd ca vector pentru exploatarea unei vulnerabilități recente de tip root în Solaris (CVE-2020-14871).
• Modificări care ar putea afecta compatibilitatea:
  • În ssh și sshd a fost reproiectată o metodă experimentală de schimb de chei, rezistentă la atacurile realizate de computere cuantice. Computerele cuantice rezolvă mult mai rapid problema descompunerii unui număr natural în factori primi, care stă la baza algoritmilor moderni de criptare asimetrică și este eficient imposibil de rezolvat pe procesoare clasice. Metoda utilizată se bazează pe algoritmul NTRU Prime, dezvoltat pentru criptosisteme post-cuante, și pe metoda de schimb de chei bazată pe curbele eliptice X25519. În loc de sntrup4591761x25519-sha512@tinyssh.org, metoda este acum identificată ca sntrup761x25519-sha512@openssh.com (algoritmul sntrup4591761 a fost înlocuit cu sntrup761).
  • În ssh și sshd a fost modificată ordinea de anunțare a algoritmilor de semnătură digitală acceptați. Acum, primul propus este ED25519 în loc de ECDSA.
  • În ssh și sshd, setarea parametrilor de calitate a serviciului TOS/DSCP pentru sesiuni interactive se face acum înainte de stabilirea conexiunii TCP.
  • În ssh și sshd a fost retras suportul pentru cifrul rijndael-cbc@lysator.liu.se, care este identic cu aes256-cbc și a fost utilizat până la aprobarea RFC-4253.
  • Parametrul CheckHostIP este dezactivat în mod implicit, beneficiul său fiind neglijabil, dar utilizarea sa complică semnificativ rotația cheilor pentru gazde în spatele echilibratoarelor de sarcină.
• În sshd au fost adăugate setările PerSourceMaxStartups și PerSourceNetBlockSize pentru a limita intensitatea lansării handler-elor în funcție de adresa clientului. Aceste parametru permit o gestionare mai fină a limitării lansării proceselor, în comparație cu setarea generală MaxStartups.
• În ssh și sshd a fost adăugată o nouă setare LogVerbose, care permite ridicarea forțată a nivelului de logare a informațiilor de debugging, cu posibilitatea de filtrare pe baza tiparelor, funcțiilor și fișierelor.
• În ssh, la acceptarea unei noi chei de gazdă, se garantează afișarea tuturor numelui gazdelor și adreselor IP, asociate cu cheia.
• În ssh, este permisă specificarea opțiunii UserKnownHostsFile=none pentru a dezactiva utilizarea fișierului known_hosts în timpul identificării cheilor de gazdă.
• În ssh_config pentru ssh a fost adăugată setarea KnownHostsCommand, care permite obținerea datelor known_hosts din ieșirea unei comenzi specificate.
• În ssh_config pentru ssh a fost adăugată opțiunea PermitRemoteOpen, care permite restricționarea punctului de destinație la utilizarea opțiunii RemoteForward cu SOCKS.
• În ssh, pentru cheile FIDO, a fost implementată o solicitare repetată a PIN-ului în cazul unui eșec al operației de semnătură digitală din cauza unui PIN incorect și a absenței unei solicitări de PIN de la utilizator (de exemplu, atunci când nu s-au obținut date biometrice corecte și dispozitivul a revenit la introducerea manuală a PIN-ului).
• În sshd, mecanismul de izolare a proceselor bazat pe seccomp-bpf pe platforma Linux a fost extins cu suport pentru apeluri de sistem suplimentare.
• Utilitarul contrib/ssh-copy-id a fost actualizat.

Sursa: opennet.ro