GnuTLS corectează eroarea de gestionare greșită a memoriei – actualizați acum!

Cea mai cunoscută bibliotecă criptografică din lumea open-source este aproape sigur OpenSSL.

În primul rând, este una dintre cele mai utilizate pe scară largă, până la punctul în care majoritatea dezvoltatorilor de pe majoritatea platformelor au auzit de el chiar dacă nu l-au folosit direct.

În al doilea rând, este probabil cel mai mediatizat, din păcate din cauza unei erori destul de urâte cunoscute sub numele de heartbleed care a fost descoperit acum mai bine de opt ani.

În ciuda faptului că a fost corectat prompt (și în ciuda unor soluții fiabile existente pentru dezvoltatorii care nu au putut sau nu și-au actualizat rapid versiunile OpenSSL vulnerabile), Heartbleed rămâne un fel de eroare „de prezentare”, nu în ultimul rând pentru că a fost unul dintre primele erori care au apărut. transformat într-un vehicul de PR agresiv de către descoperitorii săi.

Cu un nume impresionant, un logo propriu și un site web dedicat, Heartbleed a devenit rapid o companie globală de securitate cibernetică. superpovesteși, de bine sau de rău, a devenit indisolubil legată de mențiunile numelui OpenSSL, ca și cum pericolul bug-ului a continuat chiar și după ce a fost eliminat din cod.

Viața dincolo de OpenSSL

Dar există câteva alte biblioteci criptografice open-source care sunt utilizate pe scară largă, precum și sau în locul lui OpenSSL, în special inclusiv pe Mozilla. NSS (scurt pentru Servicii de securitate a rețelei) și proiectele GNU gnuTLS bibliotecă.

După cum se întâmplă, GnuTLS tocmai a corectat o eroare cunoscută ca CVE-2022-2509, raportat în proiectul consiliere de securitate GNUTLS-SA-2022-07-07.

Acest patch remediază o eroare de gestionare greșită a memoriei cunoscută sub numele de a dublu liber.

Dublu-free explicat

Mai simplu spus, o vulnerabilitate dublu-liberă este creată atunci când un programator cere sistemului de operare să aloce un bloc de memorie pentru a-l utiliza temporar...

…și îl predă înapoi, astfel încât să poată fi șters din lista de blocuri împrumutate pentru a fi eliberat pentru a fi utilizat de alte părți ale programului...

… și apoi cere accidental sistemului să elibereze din nou același bloc de memorie.

În mod ideal, software-ul de alocare a memoriei va detecta că blocul nu mai aparține părții din program care îl „returnează”, își va da seama că blocul ofensator a fost deja reciclat și nu îl va dealoca a doua oară, evitând astfel riscurile de a-l „elibera” din nou.

A face cu blândețe un dublu gratuit care este detectat în mod proactiv este o problemă dificilă. Funcția C care returnează memoria este prototipată ca void free(void *ptr); astfel încât să treci adresa unui bloc pe care vrei să-l eliberezi, dar să nu primești un cod de returnare. (Funcția AC cu a void valoarea returnată este ceea ce alte limbaje de programare numesc a procedure: face ceva pentru tine, dar nu are nicio modalitate de a raporta un rezultat.) Astfel, chiar și codul C scris cu atenție nu are un mod standard de a detecta că ceva a mers prost în free(), și, prin urmare, nicio modalitate de a gestiona eroarea încercând să se închidă cu grație. Încheierea unilaterală a programului ofensator este singura soluție sigură pentru sistem.

Dar dacă alocatorul de memorie nu își dă seama (poate pentru că același bloc a fost distribuit de atunci unei alte părți a aceluiași program, deci este din nou în lista „împrumutate” în exact aceeași formă ca înainte) , atunci este posibil să se întâmple lucruri rele.

În special, managerul de memorie ar putea „confisca” în mod neatenționat și neașteptat blocul dublu eliberat din codul care îl folosește acum în mod legitim și îl poate reatribui unei alte părți a programului, poate chiar unui cod rău intenționat pe care un atacator l-a cronometrat cu atenție pentru a profita. a proastei gestiuni.

Deci, puteți ajunge cu două părți ale aceluiași program care manipulează aceeași bucată de memorie.

O parte a programului presupune că poate avea încredere în conținutul memoriei implicit, deoarece se consideră „proprietarul” legitim al blocului.

În același timp, o altă parte a programului știe că se poate încurca cu datele (sau poate fi păcălit să se încurce cu ele) pentru a declanșa prima parte în mod deliberat.

A face lucrul greșit face ceea ce trebuie

În mod ironic, eroarea CVE-2022-2509 există în codul de verificare a certificatului din GnuTLS.

(Ironia, în cazul în care vă întrebați, este că software-ul care este nesigur în general, deoarece nu se deranjează să verifice conexiunile TLS de încredere este imun la acest bug de securitate specific.)

De exemplu, când vizitați un site web (sau alt tip de server) care este securizat cu TLS, celălalt capăt vă va trimite de obicei un certificat web care afirmă că serverul este într-adevăr deținut și operat de organizația la care vă așteptați.

Bineînțeles, având în vedere că oricine poate crea un certificat cu orice nume dorește, un certificat brut în sine nu vă spune prea multe, așa că proprietarul certificatului îl obține de obicei semnat digital de o companie în care browserul dvs. are deja încredere.

În practică, certificatele sunt de obicei semnate de un certificat care este, la rândul său, semnat de un certificat în care browserul dvs. are încredere, dar rezultatul final este ceea ce se numește lanț de încredere care poate fi urmărit în siguranță la un certificat care este deja instalat într-o listă de așa-numite Autorități de încredere, de asemenea cunoscut ca si Radacini, care este gestionat de browser sau de sistemul de operare.

Pentru a simplifica și a accelera procesul de validare a lanțului de certificate, multe servere nu își trimit doar propriul certificat și îl lasă browserului să „urmeze lanțul” la o rădăcină de încredere.

Serverul include de obicei lanțul de încredere pe care se bazează, pe care trebuie să îl construiască o singură dată, astfel încât browserul dvs. sau orice software care verifică certificatul să poată verifica pur și simplu dacă lanțul este valid digital și apoi să verifice dacă ultimul certificat în lanț se potrivește cu unul care este deja de încredere.

În acest caz, GnuTLS va valida corect și în siguranță certificatul furnizat, înainte de a elibera blocul de memorie folosit tocmai pentru a-l stoca.

Dar dacă celălalt capăt nu oferă un lanț de certificate pre-generat, lăsând astfel GnuTLS să creeze și să verifice lanțul singur, atunci codul GnuTLS eliberează accidental memoria folosită pentru a stoca certificatul furnizat înainte de a începe lanțul. procesul de verificare...

… și apoi îl eliberează din nou după ce verificarea este finalizată.

Acest lucru provoacă o accidentare dublu-liberă, care ar putea duce la coruperea memoriei, urmată de o prăbușire a programului.

Păstoresc un accident pentru a implanta malware

De obicei, sau cel puțin adesea, blocările provoacă un comportament atât de obositor încât sistemul de operare detectează că programul ofensator și-a pierdut controlul asupra fluxului de execuție a programului – de exemplu, dacă programul trece la o adresă de memorie aleatorie și încearcă să ruleze cod dintr-un bloc de memorie care nu a fost deloc alocat.

În acest caz, prăbușirea ar provoca o eroare de sistem și, deși acest tip de eroare ar putea fi abuzat pentru ceea ce se numește Denial of Service (DoS), în care scopul întreg este pur și simplu de a perturba programul atacat, nu duce la Executarea codului la distanță (RCE), unde se declanșează în schimb codul software neîncrezat și nedorit.

Dar, ori de câte ori există o prăbușire a unui program pe care atacatorii o pot provoca după bunul plac, pe baza datelor nesigure pe care le-au furnizat ei înșiși, există întotdeauna riscul ca prăbușirea să fie controlată în așa fel încât să direcționeze greșit programul care se prăbușește, astfel încât să sară în codul executabil furnizat. de către atacatori.

După cum vă puteți imagina, atacatorii pot exploata adesea astfel de vulnerabilități pentru a implanta malware, fie temporar, fie permanent, având în vedere că ajung să injecteze cod neîncrezător în computerul dvs. fără a produce avertismente pop-up care să solicite mai întâi permisiunea.

Ce să fac?

Actualizați la ultima versiune de GnuTLS, care este 3.7.7 la momentul scrisului.

(Această eroare a fost aparent introdusă în GnuTLS 3.6.0 și există în fiecare versiune de atunci, până la 3.7.6 inclusiv.)

Rețineți că multe aplicații populare și seturi de instrumente de programare fie includ sau pot fi construite pentru a utiliza GnuTLS, chiar dacă este posibil să nu știți, inclusiv, dar nu se limitează la: FFmpeg, GnuPG, Mplayer, QEMU, Rdesktop, Samba, Wget, Wireshark și Zlib.

Multe pachete Linux sau *BSD care folosesc GnuTLS se vor baza pe o versiune centrală gestionată de distribuția dvs. în sine, așa că asigurați-vă că actualizați imediat ce distribuția dvs. are această versiune disponibilă.

Patch fericit!

---