Despre CVE-2024-0517
CVE-2024-0517 este o vulnerabilitate de tip „scriere în afara limitelor” în motorul JavaScript V8 al browserului Google Chrome, în versiunile anterioare versiunii 120.0.6099.224, care permite atacatorilor la distanță să exploateze o corupție a memoriei heap prin intermediul unei pagini HTML special create. Vulnerabilitatea a fost semnalată pentru prima dată de Toan (Suto) Pham de la Qrious Secure.
Această vulnerabilitate provine din confuzia de tip, care apare atunci când o aplicație alocă sau inițializează o resursă, cum ar fi un pointer, un obiect sau o variabilă, folosind un tip, dar ulterior accesează acea resursă folosind un tip care este incompatibil cu tipul inițial (CWE-843). În acest CVE, confuzia de tip este declanșată în timpul unui proces de alocare a memoriei numit alocare pliată, care este utilizat pentru optimizarea memoriei de către Maglev, un compilator optimizator pentru motorul JavaScript V8.
Exploatând confuzia de tip și scriind coduri shell arbitrare prin WebAssembly, un atacator poate executa comenzi pe computerul victimei.
Fazele atacului
Atacatorii pot găzdui un site web care conține o pagină HTML modificată și pot păcăli utilizatorii să îl acceseze prin e-mailuri de phishing sau rețele sociale. Atunci când utilizatorii vizitează site-ul folosind o versiune vulnerabilă de Google Chrome, codul malițios încorporat va executa comenzi arbitrare.
Motor JavaScript V8
Motorul JavaScript V8 a fost scris în C++ de Google și lansat pe 2 septembrie 2008.V8 compilează și execută codul sursă JavaScript, gestionează alocarea de memorie pentru obiecte și colectează obiectele de care nu mai are nevoie. V8 este o componentă de bază a Google Chrome și poate fi încorporat în orice aplicație C++, cum ar fi Node.js, pentru a executa cod JavaScript sau WebAssembly.
Maglev și alocarea pliată
Maglev, un compilator optimizator în V8, îmbunătățește execuția codului și alocarea memoriei. Maglev rulează numai atunci când codul este executat frecvent și marcat ca fiind "fierbinte", indicând necesitatea unei execuții mai rapide prin compilare, mai degrabă decât o interpretare mai lentă linie cu linie.
De obicei, alocările au loc în regiuni de memorie necontigue, ceea ce conduce la o utilizare dispersată și ineficientă a memoriei. Pentru a rezolva această problemă, V8 utilizează o tehnică numită alocare pliată, care alocă mai multe variabile în mod continuu și simultan. Maglev optimizează, de asemenea, alocările prin utilizarea alocării pliate în progresul său.
Colectarea generațională a gunoiului
Pentru a curăța regiunile de memorie neutilizate, V8 utilizează o tehnică generațională de colectare a gunoiului (GC), împărțind memoria în două spații: generația tânără și generația veche. În plus, există două colectori de gunoi: colectorul de gunoi minor, care este responsabil de curățarea spațiului tânăr, și colectorul de gunoi major, care se ocupă de curățarea spațiului vechi. Generația tânără este zona de memorie în care sunt alocate inițial obiectele nou create, iar generația veche este o regiune de memorie în care sunt stocate obiectele de lungă durată. Obiectele care au supraviețuit mai multor cicluri GC minore în generația tânără sunt în cele din urmă promovate în generația veche.
Analiza vulnerabilității
Prezentare generală
Vulnerabilitatea apare atunci când un obiect este creat dintr-o clasă moștenită de la o clasă de bază fără constructor definit explicit (constructor implicit de bază), iar ulterior este creat un alt obiect. Datorită alocării pliate, alocarea primului obiect poate fi urmată de alocarea celui de-al doilea obiect. Dacă între aceste două alocări are loc un eveniment cum ar fi colectarea gunoiului, poate apărea o vulnerabilitate de confuzie de tip.
Analiza cauzelor principale
OPSWAT Graduate Fellows au efectuat o analiză detaliată a fluxului de lucru V8 în timpul procesului de alocare și au stabilit că următoarele funcții sunt invocate în timpul acestui proces:
În cadrul acestui proces, a fost identificată o problemă în funcția TryBuildFindNonDefaultConstructorOrConstruct: Funcția BuildAllocateFastObject extinde current_raw_allocation_ (un pointer către regiunea de memorie alocată pentru mai multe variabile simultan) pentru a construi instanța clasei copil, dar nu reușește să o șteargă prin setarea acesteia la null.
Ca urmare, următorul obiect creat este întotdeauna alocat imediat după memoria indicată de current_raw_allocation_, indiferent de orice eveniment anterior celei de-a doua alocări.
Dacă GC este invocat, regiunea de memorie adiacentă memoriei adiacente la current_raw_allocation_ poate fi atribuită altor obiecte. Acest lucru poate duce la o situație în care, după ce GC este declanșat și este creat un alt obiect, doi pointeri fac trimitere la aceeași regiune de memorie, dar au tipuri de date diferite, ceea ce duce la o vulnerabilitate de confuzie de tip.
Exploatare
Pentru a exploata această vulnerabilitate, OPSWAT Graduate Fellows au creat instanțe WebAssembly conținând cod shell și au încercat să declanșeze confuzia de tip prin GC pentru a controla memoria și a executa codul shell:
Confuzia tipului de declanșator
În timpul inițializării, definim mai întâi un array (_arrayObject) care conține obiecte goale. În continuare, construim o instanță a clasei copil, precum și un trigger garbage collector. În cele din urmă, definim un alt array cu un număr în virgulă mobilă, denumit _arrayDouble.
Aceste construcții trebuie să fie repetate astfel încât codul să fie executat de mai multe ori, determinând V8 să îl marcheze ca "fierbinte" și să declanșeze compilatorul Maglev. Obținem acest lucru prin invocarea constructorului clasei copil în cadrul unei bucle, după cum urmează:
Confuzia de tip va fi declanșată după inițializarea repetată a acestor obiecte într-o buclă.
Crearea de primitive de citire și scriere
După declanșarea cu succes a confuziei de tip, execuția codului shell necesită citirea memoriei și suprascrierea memoriei la o adresă controlată. Pentru a face acest lucru, am creat primitive de citire și scriere. Primitivele de exploatare vor profita de metadatele din obiecte pentru a ne oferi regiuni de memorie arbitrare de citire/scriere și le vor utiliza pentru a executa cod arbitrar.
Primitivele de citire și scriere din acest pas ne vor permite să controlăm pointerul tabelului Jump al instanței WebAssembly în pasul următor.
Crearea instanțelor WebAssembly
În continuare, am creat două instanțe WebAssembly: una pentru stocarea codului secret și alta pentru declanșarea acestuia. Pentru a evita scrierea directă a codului shell în memoria instanței WebAssembly prin intermediul primitivelor de citire și scriere, definim unele valori constante în virgulă mobilă în cadrul instanței WebAssembly.
Pointerul tabelei de salt de control al instanței WebAssembly
Utilizând primitive de citire și scriere, ajustăm pointerul tabelului de salt al celei de-a doua instanțe WebAssembly pentru a sări peste câțiva octeți din codul compilat al constantelor din prima instanță WebAssembly, astfel încât constantele în virgulă mobilă să fie interpretate ca fiind codul de cochilie dorit:
Rulați instanța WebAssembly pentru a executa codul Shell
În cele din urmă, după declanșarea confuziei de tip și utilizarea primitivelor de citire/scriere pentru a controla indicatorii tabelei de salturi a instanțelor WebAssembly, am invocat funcția exportată a celei de-a doua instanțe WebAssembly, care determină executarea codului shell din prima instanță WebAssembly.
Codul shell pe care îl folosim este conceput pentru a termina toate procesele de pe o mașină Linux, ca prin următoarea comandă:
Codul de asamblare pentru executarea acestei comenzi, convertit din numere în virgulă mobilă, va fi după cum urmează:
Simularea vulnerabilității de securitate
Pentru a simula această exploatare într-un scenariu real, OPSWAT Graduate Fellows au creat o pagină HTML creată în mod malițios.
Victimei i se trimite un e-mail de phishing cu un link către domeniul care găzduiește această pagină HTML trucată.
Dacă victima accesează link-ul utilizând versiunea vulnerabilă a Google Chrome, shellcode-ul este executat, provocând terminarea tuturor proceselor. Ca urmare, utilizatorul este deconectat, după cum se arată mai jos:
Remediere
MetaDefender Endpoint™ a fost utilizat pentru a atenua în mod proactiv acest CVE prin utilizarea capacității sale "Aplicație vulnerabilă". Soluția identifică și afișează în mod eficient toate CVE-urile asociate pentru aplicațiile Google Chrome din mediul endpoint. Pentru a neutraliza amenințarea, utilizatorii pot dezinstala imediat Chrome sau pot aplica cel mai recent patch de securitate. Prin punerea în aplicare a ambelor contramăsuri, CVE este complet izolat, reducând semnificativ riscul unui atac cibernetic de succes asupra punctului final.
Securitatea Endpoint de nivel următor
Descoperiți de ce organizațiile, instituțiile și entitățile din întreaga lume au încredere în MetaDefender Endpoint pentru a proteja punctele finale critice. Discutați astăzi cu un expert pentru a afla mai multe și convingeți-vă cu o demonstrație gratuită.
Referințe
https://nvd.nist.gov/vuln/detail/CVE-2024-0517
https://cwe.mitre.org/data/definitions/843.html
https://blog.exodusintel.com/2024/01/19/google-chrome-v8-cve-2024-0517-out-of-bounds-write-code-execution/
https://jhalon.github.io/chrome-browser-exploitation-1/
https://whenderson.dev/blog/webgl-garbage-collection/
https://v8.dev/
https://github.com/Uniguri/CVE-nday/tree/master/Chrome/V8/CVE-2024-0517
