Versiunea OpenSSH 8.3 remediază vulnerabilitatea scp

După trei luni de dezvoltare prezentat eliberare OpenSSH 8.3, o implementare deschisă pentru client și server pentru lucrul prin protocoalele SSH 2.0 și SFTP.

Noua versiune adaugă protecție împotriva atacurilor scp care permit serverului să treacă alte nume de fișier decât cele solicitate (spre deosebire de vulnerabilitatea trecută, atacul nu face posibilă schimbarea directorului selectat de utilizator sau a măștii glob). Amintiți-vă că în SCP, serverul decide ce fișiere și directoare să trimită clientului, iar clientul verifică doar corectitudinea numelor obiectelor returnate. Esența problemei identificate este că, dacă apelul de sistem utimes eșuează, atunci conținutul fișierului este interpretat ca metadate ale fișierului.

Această caracteristică, atunci când vă conectați la un server controlat de un atacator, poate fi folosită pentru a salva alte nume de fișiere și alt conținut în FS-ul utilizatorului atunci când copiați folosind scp în configurații care duc la eșec la apelarea utimes (de exemplu, când utimes este interzis de politica SELinux sau filtrul de apeluri de sistem) . Probabilitatea unor atacuri reale este estimată a fi minimă, deoarece în configurațiile tipice apelul utimes nu eșuează. În plus, atacul nu trece neobservat - la apelarea scp, este afișată o eroare de transfer de date.

Modificări generale:

• În sftp, procesarea argumentului „-1” a fost oprită, similar cu ssh și scp, care a fost acceptat anterior, dar ignorat;
• În sshd, când utilizați IgnoreRhosts, există acum trei opțiuni: „da” - ignorați rhosts/shosts, „no” - respectați rhosts/shosts și „shosts-only” - permiteți „.shosts” dar dezactivați „.rhosts”;
• Ssh acceptă acum înlocuirea %TOKEN în setările LocalFoward și RemoteForward utilizate pentru a redirecționa socket-urile Unix;
• Permite încărcarea cheilor publice dintr-un fișier necriptat cu o cheie privată dacă nu există un fișier separat cu cheia publică;
• Dacă libcrypto este prezent în sistem, ssh și sshd utilizează acum implementarea algoritmului chacha20 din această bibliotecă, în loc de implementarea portabilă încorporată, care rămâne în urmă în performanță;
• A implementat capacitatea de a descărca conținutul unei liste binare de certificate revocate la executarea comenzii „ssh-keygen -lQf /path”;
• Versiunea portabilă implementează definiții ale sistemelor în care semnalele cu opțiunea SA_RESTART întrerup operarea selectării;
• Problemele de construcție pe sistemele HP/UX și AIX au fost rezolvate;
• S-au rezolvat problemele legate de construirea seccomp sandbox pe unele configurații Linux;
• Detectarea bibliotecii libfido2 îmbunătățită și problemele de compilare rezolvate cu opțiunea „--with-security-key-builtin”.

Dezvoltatorii OpenSSH au avertizat încă o dată cu privire la descompunerea iminentă a algoritmilor care utilizează hash-uri SHA-1 din cauza promovare eficacitatea atacurilor de coliziune cu un prefix dat (costul de selectare a unei coliziuni este estimat la aproximativ 45 de mii de dolari). Într-una dintre edițiile viitoare, aceștia intenționează să dezactiveze implicit capacitatea de a utiliza algoritmul de semnătură digitală cu cheie publică „ssh-rsa”, care este menționat în RFC original pentru protocolul SSH și rămâne larg răspândit în practică (pentru a testa utilizarea de ssh-rsa în sistemele dvs., puteți încerca să vă conectați prin ssh cu opțiunea „-oHostKeyAlgorithms=-ssh-rsa”).

Pentru a ușura tranziția la noi algoritmi în OpenSSH, într-o versiune viitoare setarea UpdateHostKeys va fi activată implicit, ceea ce va migra automat clienții către algoritmi mai fiabili. Algoritmii recomandați pentru migrare includ rsa-sha2-256/512 bazat pe RFC8332 RSA SHA-2 (acceptat începând cu OpenSSH 7.2 și utilizat implicit), ssh-ed25519 (acceptat începând cu OpenSSH 6.5) și ecdsa-sha2-nistp256/384 based pe RFC521 ECDSA (acceptat începând cu OpenSSH 5656).

Începând cu ultima ediție, „ssh-rsa” și „diffie-hellman-group14-sha1” au fost eliminate din lista CASignatureAlgorithms care definește algoritmii care permit semnarea digitală a certificatelor noi, deoarece utilizarea SHA-1 în certificate prezintă un risc suplimentar. din acest motiv, atacatorul are timp nelimitat pentru a căuta o coliziune pentru un certificat existent, în timp ce timpul de atac asupra cheilor gazdei este limitat de expirarea conexiunii (LoginGraceTime).

Sursa: opennet.ru