Securitate serioasă: GnuTLS urmează OpenSSL, remediază erorile de atac de sincronizare

Săptămâna trecută, am scris despre o grămadă de erori de gestionare a memoriei care au fost remediate în cea mai recentă actualizare de securitate a popularei biblioteci de criptare OpenSSL.

Alături de acele erori de memorie, am raportat și o eroare numită CVE-2022-4304: Timing Oracle în RSA Decryption.

În acest bug, lansarea aceluiași mesaj criptat din nou și din nou la un server, dar modificarea umpluturii la sfârșitul datelor pentru a face datele invalide și provocând astfel un fel de comportament imprevizibil...

… nu ar dura o perioadă consistentă de timp, presupunând că sunteți aproape de ținta din rețea, ați putea ghici în mod fiabil cât timp va dura partea de transfer de date a procesului.

Nu toate datele sunt prelucrate în mod egal

Dacă declanșați o solicitare, timpul cât durează răspunsul și scadeți timpul consumat în trimiterea și primirea de nivel scăzut a datelor din rețea, știți cât timp a durat serverul pentru a face calculul intern pentru a procesa cererea. .

Chiar dacă nu sunteți sigur cât timp este folosit în rețea, puteți căuta variații în timpul de călătorie dus-întors, lansând o mulțime de solicitări și colectând o mulțime de mostre.

Dacă rețeaua este suficient de fiabilă pentru a presupune că suprasarcina de rețea este în mare parte constantă, este posibil să puteți utiliza metode statistice pentru a deduce ce fel de modificare a datelor cauzează ce fel de întârziere suplimentară de procesare.

Din aceasta, mulți puteți deduce ceva despre structura sau chiar conținutul datelor originale necriptate care ar trebui să fie păstrate secrete în cadrul fiecărei solicitări repetate.

Chiar dacă puteți extrage doar un octet de text simplu, ei bine, asta nu ar trebui să se întâmple.

Așa-zisul atacuri de sincronizare de acest fel sunt întotdeauna supărătoare, chiar dacă ar putea fi nevoie să trimiteți milioane de pachete false și să le programați pe toate pentru a avea vreo șansă de a recupera doar un octet de date în text simplu...

… pentru că rețelele sunt mai rapide, mai previzibile și capabile să suporte mult mai multă sarcină decât erau acum câțiva ani.

Ai putea crede că milioane de pachete perfide ți-au trimis spam în, să zicem, următoarea oră, ar ieși în evidență ca un fel de degetul mare.

Dar „un milion de pachete pe oră mai mult sau mai puțin decât de obicei” pur și simplu nu mai este o variație deosebit de mare.

Bug similar „oracol” în GnuTLS

Ei bine, aceeași persoană care a raportat eroarea de sincronizare a erorii remediate în sfârșit în OpenSSL a raportat și o bug similar în GnuTLS cam in acelasi timp.

Acesta are identificatorul de eroare CVE-2023-0361.

Deși GnuTLS nu este la fel de popular sau de utilizat pe scară largă ca OpenSSL, probabil că aveți o serie de programe în domeniul IT, sau chiar pe propriul computer, care îl folosesc sau îl includ, inclusiv FFmpeg, GnuPG, Mplayer, QEMU , Rdesktop, Samba, Wget și Wireshark.

În mod ironic, defectul de sincronizare din GnuTLS a apărut în codul care trebuia să înregistreze erorile de atac de sincronizare în primul rând.

După cum puteți vedea din diferența de cod (dif) de mai jos, programatorul era conștient de faptul că orice condițional (if ... then) operațiunea utilizată în verificarea și tratarea unei erori de decriptare poate produce variații de sincronizare, deoarece CPU-urile durează, în general, o perioadă diferită de timp, în funcție de direcția în care merge codul după o instrucțiune de „ramură”.

(Acest lucru este valabil mai ales pentru o ramură care merge adesea într-un sens și rareori în celălalt, deoarece procesoarele tind să-și amintească sau să memoreze în cache codul care rulează în mod repetat pentru a îmbunătăți performanța, făcând astfel ca codul preluat rar să ruleze mai lent.)

Dar programatorul a vrut totuși să înregistreze că ar putea avea loc un atac, ceea ce se întâmplă dacă if (ok) testul de mai sus eșuează și se ramifică în else { ... } secţiune.

În acest moment, codul apelează _gnutls_debug_log() funcția, care ar putea dura destul de mult pentru a-și face treaba.

Prin urmare, codificatorul a introdus un apel deliberat la _gnutls_no_log() în then { ... } parte a codului, care pretinde că înregistrează un „atac” atunci când nu există, pentru a încerca să uniformizeze timpul pe care codul îl petrece în oricare direcție în care if (ok) instructiunea de ramura poate lua.

Aparent, totuși, cele două căi de cod nu erau suficient de asemănătoare în timpul pe care l-au folosit (sau poate că _gnutls_debug_log() funcția în sine a fost insuficient de consecventă în a face față diferitelor tipuri de erori), iar un atacator ar putea începe să distingă indicii de decriptare după aproximativ un milion de încercări.

Ce să fac?

Daca esti programator: Remedierea erorilor aici a fost simplă și a urmat principiul „mai puțin este mai mult”.

Codul în roz de mai sus, despre care se consideră că oricum nu oferă date teribil de utile de detectare a atacurilor, a fost pur și simplu șters, pe motiv că codul care nu există nu poate fi compilat din greșeală, indiferent de setările dvs. de construcție...

… iar codul care nu este compilat nu poate rula niciodată, fie din întâmplare, fie prin proiect.

Dacă sunteți utilizator GnuTLS: versiunea recent lansată 3.7.9 și „aroma de produs nou” 3.8.0 au această remediere, împreună cu diverse altele, incluse.

Dacă rulați o distribuție Linux, verificați dacă există actualizări pentru orice versiune de bibliotecă partajată centralizată a GnuTLS pe ​​care o aveți, precum și pentru aplicațiile care aduc propria lor versiune.

Pe Linux, căutați fișiere cu numele libgnutls*.so pentru a găsi biblioteci partajate în jur și căutați gnutls-cli pentru a găsi orice copii ale utilitarului de linie de comandă care este adesea inclus în bibliotecă.

Poți alerga gnutls-cli -vv pentru a afla ce versiune a libgnutls este legat dinamic de:

 $ gnutls-cli -vv gnutls-cli 3.7.9 <-- Distro-ul meu Linux a primit actualizarea vinerea trecută (2023-02-10)

---

• Distribuție de conținut bazat pe SEO și PR. Amplifică-te astăzi.
• Platoblockchain. Web3 Metaverse Intelligence. Cunoștințe amplificate. Accesați Aici.
• Sursa: https://nakedsecurity.sophos.com/2023/02/13/serious-security-gnutls-follows-openssl-fixes-timing-attack-bug/