A CVE-2024-0517-ről
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.
Ez a sebezhetőség a típuskeveredésből ered, amely akkor fordul elő, amikor egy alkalmazás egy erőforrást, például egy mutatót, objektumot vagy változót egy típus használatával rendel ki vagy inicializál, de később az erőforráshoz egy olyan típussal fér hozzá, amely nem kompatibilis az eredeti típussal (CWE-843). Ebben a CVE-ben a típuskeveredés a memóriaelosztás folded allocation nevű folyamata során következik be, amelyet a V8 JavaScript motor optimalizáló fordítója, a Maglev alkalmaz memóriaoptimalizálás céljából.
A típuszavar kihasználásával és tetszőleges héjkódok WebAssembly segítségével történő írásával a támadó parancsokat hajthat végre az áldozat gépén.
Támadó fázisok
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.
V8 JavaScript motor
A V8 JavaScript motort a Google C++ nyelven írta, és 2008. szeptember 2-án adta ki.A V8 lefordítja és végrehajtja a JavaScript forráskódot, kezeli az objektumok memóriaelosztását, és a már nem szükséges objektumokat szemétbe gyűjti. A V8 a Google Chrome alapvető összetevője, és beágyazható bármely C++ alkalmazásba, például a Node.js-be, hogy JavaScript vagy WebAssembly kódot hajtson végre.
Maglev és hajtogatott elosztás
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.
Generációs szemétgyűjtés
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.
Sebezhetőségi elemzés
Áttekintés
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.
Gyökeres okok elemzése
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 folyamat során a TryBuildFindNonDefaultConstructorOrConstruct függvényben egy problémát azonosítottak: A BuildAllocateFastObject függvény kiterjeszti a current_raw_allocation_-t (az egyszerre több változó számára kiosztott memóriarégióra mutató mutatót) a gyermek osztálypéldány megkonstruálására, de nem törli azt nullára állítva.
Ennek eredményeként a következő létrehozott objektum mindig közvetlenül a current_raw_allocation_ által mutatott memória után kerül kiosztásra, függetlenül a második kiosztás előtti eseményektől.
Ha a GC meghívásra kerül, a current_raw_allocation_ szomszédos memóriaterület melletti memóriaterületet más objektumokhoz lehet hozzárendelni. Ez olyan helyzethez vezethet, amikor a GC kiváltása és egy másik objektum létrehozása után két mutató hivatkozik ugyanarra a memóriarégióra, de különböző adattípusokkal, ami típuszavaros sebezhetőséget eredményez.
Kihasználás
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:
Triggertípus zűrzavar
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.
Ezeket a konstrukciókat meg kell ismételni, hogy a kód többször is végrehajtódjon, aminek hatására a V8 "forrónak" jelöli és elindítja a Maglev fordítót. Ezt úgy érjük el, hogy egy cikluson belül meghívjuk a gyermekosztály konstruktorát az alábbiak szerint:
A típuszavar azután fog bekövetkezni, hogy ezeket az objektumokat egy ciklusban ismételten inicializálják.
Olvasási és írási primitívek létrehozása
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.
Az olvasási és írási primitívek ebben a lépésben lehetővé teszik számunkra, hogy a következő lépésben a WebAssembly-példány Ugrótábla mutatóját irányítsuk.
WebAssembly példányok létrehozása
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.
A WebAssembly-példány vezérlőugrás-táblázatának mutatója
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:
WebAssembly példány futtatása a Shellcode végrehajtásához
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:
A lebegőpontos számokból konvertált assembly kód a következőképpen néz ki a parancs végrehajtásához:
A biztonsági sebezhetőség szimulálása
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.
Az áldozatnak egy olyan adathalász e-mailt küldenek, amelybe beágyazva egy linket tartalmaz a hamisított HTML-oldalnak otthont adó tartományra.
Ha az áldozat a Google Chrome sebezhető verziójával lép be a linkre, a shellcode végrehajtódik, és minden folyamat leáll. Ennek eredményeképpen a felhasználó kijelentkezik, ahogy az alább látható:
Helyreállítás
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.
Következő szintű Endpoint biztonság
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.
Hivatkozások
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
