A CVE-2024-0517 sebezhetőség elhárítása a Google Chrome-ban

A CVE-2024-0517 a Google Chrome 120.0.6099.224 verzió előtti V8 JavaScript motorjában található egy out-of-bounds write sebezhetőség, amely lehetővé teszi a távoli támadók számára, hogy kihasználják a halom sérülését egy szerkesztett HTML oldalon keresztül. A sebezhetőséget először Toan (Suto) Pham, a Qrious Secure munkatársa jelentette. 

A támadók egy hamisított HTML-oldalt tartalmazó webhelyet üzemeltethetnek, és becsaphatják a felhasználókat, hogy adathalász e-maileken vagy a közösségi hálózatokon keresztül hozzáférjenek a webhelyhez. Amikor a felhasználók a Google Chrome sebezhető verziójával látogatják meg a webhelyet, a beágyazott rosszindulatú kód tetszőleges parancsokat hajt végre. 

A támadók egy hamisított HTML-oldalt tartalmazó webhelyet üzemeltethetnek, és becsaphatják a felhasználókat, hogy adathalász e-maileken vagy a közösségi hálózatokon keresztül hozzáférjenek a webhelyhez. Amikor a felhasználók a Google Chrome sebezhető verziójával látogatják meg a webhelyet, a beágyazott rosszindulatú kód tetszőleges parancsokat hajt végre. 

A V8 optimalizáló fordítója, a Maglev javítja a kódfuttatást és a memóriaelosztást. A Maglev csak akkor fut, ha a kódot gyakran hajtják végre és "forrónak" jelölik, ami azt jelzi, hogy a lassabb soronkénti értelmezés helyett a fordítással történő gyorsabb végrehajtásra van szükség. 

A kiosztások általában nem összefüggő memóriarégiókban történnek, ami ritkás és nem hatékony memóriahasználatot eredményez. Ennek kezelésére a V8 a hajtogatott allokációnak nevezett technikát alkalmazza, amely több változót folyamatosan és egyidejűleg allokál. A Maglev szintén optimalizálja a kiosztásokat a hajtogatott kiosztás alkalmazásával a haladás során. 

A nem használt memóriarégiók megtisztítására a V8 generációs szemétgyűjtési (GC) technikát alkalmaz, amely a memóriát két területre osztja: a fiatal és az öreg generációra. Ezen kívül két szemétgyűjtő van: a minor szemétgyűjtő, amely a fiatal terület megtisztításáért felelős, és a major szemétgyűjtő, amely a régi terület megtisztítását végzi. A fiatal generáció a memóriának az a területe, ahol az újonnan létrehozott objektumokat kezdetben hozzárendelik, a régi generáció pedig a memóriának az a régiója, ahol a hosszú életű objektumok tárolódnak. Azok az objektumok, amelyek több kisebb GC-ciklust is túléltek a fiatal generációban, végül átkerülnek a régi generációba. 

A sebezhetőség akkor keletkezik, amikor egy objektumot egy olyan bázisosztályból örökölt osztályból hozunk létre, amelynek nincs explicit módon definiált konstruktora (bázis alapértelmezett konstruktora), és ezt követően egy másik objektumot hozunk létre. A hajtogatott kiosztás miatt az első objektum kiosztását követheti a második objektum kiosztása. Ha e két allokáció között olyan esemény következik be, mint például a szemétgyűjtés, akkor típuszavaros sebezhetőség léphet fel.

OPSWAT diplomás ösztöndíjasai részletesen elemezték a V8 munkafolyamatot az elosztási folyamat során, és megállapították, hogy a folyamat során a következő funkciókat hívják elő: 

A sebezhetőség kihasználásához OPSWAT diplomás ösztöndíjasai shellcode-ot tartalmazó WebAssembly példányokat hoztak létre, és megpróbáltak típuszavart kiváltani a GC segítségével, hogy a memóriát irányítsák és a shellcode-ot futtassák: 

Az inicializálás során először definiálunk egy üres objektumokat tartalmazó tömböt (_arrayObject). Ezután létrehozzuk a gyermek osztály egy példányát, valamint egy kiváltó szemétgyűjtőt. Végül definiálunk egy másik tömböt egy lebegőpontos számmal, melynek neve _arrayDouble. 

A típuszavar sikeres kiváltása után a shellcode végrehajtásához a memória kiolvasása és a memória felülírása szükséges egy ellenőrzött címen. Ehhez létrehoztunk olvasási és írási primitíveket. A kihasználási primitívek kihasználják az objektumok metaadatait, hogy tetszőleges írható/olvasható memóriarégiókat kapjunk, és ezt tetszőleges kód futtatására használjuk. 

Ezután két WebAssembly példányt hoztunk létre: egyet a shellcode tárolására, egy másikat pedig a kiváltására. Annak elkerülése érdekében, hogy a Shellcode-ot közvetlenül a WebAssembly példány memóriájába írjuk be olvasási és írási primitívek segítségével, a WebAssembly példányon belül definiálunk néhány lebegőpontos konstans értéket. 

Olvasási és írási primitívek használatával; a második WebAssembly példány ugróasztalának mutatóját úgy állítjuk be, hogy az első WebAssembly példányban lévő konstansok lefordított kódjának néhány bájtját kihagyjuk, így a lebegőpontos konstansokat a tervezett shellcode-ként értelmezzük:

Végül, miután kiváltottuk a típuskeveredést, és olvasási/írási primitíveket használtunk a WebAssembly példányok ugrótábla mutatóinak vezérlésére, meghívtuk a második WebAssembly példány exportált függvényét, amely az első WebAssembly példányban lévő shellcode végrehajtását okozza. 

Az általunk használt shellkódot úgy terveztük, hogy a Linux gépen lévő összes folyamatot leállítsa, mint a következő parancs: 

Hogy ezt a kihasználást egy valós forgatókönyvben szimulálják, OPSWAT diplomás munkatársai létrehoztak egy rosszindulatúan szerkesztett HTML-oldalt. 

A MetaDefender Endpoint™ a "sebezhető alkalmazások" képességének kihasználásával proaktívan csökkentette ezt a CVE-t. A megoldás hatékonyan azonosítja és megjeleníti a Google Chrome alkalmazások összes kapcsolódó CVE-jét a végponti környezetben. A fenyegetés semlegesítése érdekében a felhasználók azonnal eltávolíthatják a Chrome-ot, vagy alkalmazhatják a legújabb biztonsági javítást. Bármelyik ellenintézkedés végrehajtásával a CVE teljes mértékben elszigetelődik, jelentősen csökkentve a végponton végrehajtott sikeres kibertámadás kockázatát.

Fedezze fel, miért bíznak a szervezetek, intézmények és szervezetek világszerte a MetaDefender Endpoint a kritikus végpontok védelmében. Beszéljen még ma egy szakértővel, hogy többet tudjon meg, és győződjön meg róla egy ingyenes demó segítségével.