Az első részben Pinkie Pie exploitjáról kaphattunk némi áttekintést, most pedig Sergey Glazunov 60.000 dolláros darabjának leírását posztolták a chromium blogján. Ha lehet, ez talán még agyafúrtabb, mint az előző, és aki első olvasásra nem veszti el a fonalat a felénél, az hazudik.

Az első fejvakarás akkor kezdődik, mikor az ember azt látja, hogy a preparált weboldal megtekintésétől a kódfuttatásig lezajló eseménysorozat lépésszámát nagyjából 14-ig számolták. A másik elképesztő tulajdonsága az exploitnak, hogy memória korrupció nem is történik benne, más jellegű (pl. rossz jogosultságkezelés) hibák apró kockáiból lett összerakva.

Az egész egy UXSS-sel (Universal XSS) kezdődik, vagyis a támadó szkriptjét egy weboldal borogatása helyett a böngésző manipulálására lehet felhasználni. Ha ez működik, akkor azt lehet kihasználni, hogy a Chrome egy érintett HTML oldalára nem alkalmazták a Content Security Policy-t (CSP). Arról van szó, hogy vannak speciális, a chrome:// forrásból (originből - lásd még SOP) származó oldalak (pl.: chrome://about), amik csak lokális gépen, közvetlenül nyithatók meg, külső HTML-ből (http[s]) vagy pl. IFRAME-ből nem, és nekik esetenként privilegizált API hívásokhoz is hozzáférésük van. Glazunov rájött, hogy ha egy érvénytelen chrome-extension:// erőforrást akar megnyitni IFRAME-ből, akkor a háttérben betöltődik egy UXSS-sel sebezhető hibaoldal a chrome://chromewebdata forrásból, amin nem kerül alkalmazásra a CSP (ez ugyanis megfogta volna az UXSS-t). Még néhány hibát kihasználva lehetett eljutni oda, hogy a chrome://chromewebdata nevében JavaScriptet lehessen futtatni.

De ez még kevés az örömhöz. A chrome://chromewebdata nem fér hozzá érzékeny API hívásokhoz, privilégiumokat pedig nem osztogatnak csak úgy, azt "örökölni" lehet egy közvetlenül megnyitott chrome:// forrású folyamattól. Az érzékeny chrome://* oldalakra pedig többnyire működik a CSP.

A továbblépéshez a chrome://chromewebdata nyitott egy új ablakot a chrome://net-internals originbe, ami egy IFRAME-et tartalmazott. Egy újabb bug lehetővé tette, hogy az új ablakra egy Visszát hívva a WebKit azt higyje, hogy közvetlen navigációval jutottunk az oldalra, így megadott neki néhány plusz WebUI privilégiumot. Ez után az új ablakba ágyazott IFRAME nyitott egy about:blank oldalt, és egy újabb hiba kihasználásával beadta a chrome://net-internals-nak, hogy az egy közvetlen gyermek - így az about:blank megkapta a korlátozott WebUI jogokat.

Ez után az üres oldalt a chrome://downloads-ra irányítva újabb jogokat lehetett nyerni, mivel a WebKit úgy látta, egy már részben privilegizált oldal kíván a letöltésekkel ügyködni. Ezután Glazunov fogta, és letöltött egy távoli DLL-t, majd a helyi fájlrendszerről a wordpad.exe-t. Mivel a wordpad.exe a helyi hosztról származott, elindítása nem eredményezett figyelmeztetést a felhasználó számára. A szövegszerkesztő azonban buta módon automatikusan betöltötte a mellé lerakott támadó DLL-t - egyszerűen brilliáns!

Az exploit tehát nagyjából ezen az úton haladt:

• találni olyan hibákat, amivel a támadó chrome://<valami> origin-t tud uralni (ez esetben chromewebdata és net-internals)
• ezt felruházni megfelelő jogosultságokkal
• letölteni a támadó által megadott dll-t és egy megbízható programba berántva kódot futtatni rajta keresztül

Nagyjából ennyi a Chromium blog postja, de a végén figyelmeztetnek, hogy ez korántsem a teljes kép. Például csak az UXSS-t háromszor kellett használni. Az egész eléggé magáért beszél: azokban a termékekben, amelyek fejlesztésekor komolyan veszik a biztonságot, elmúlt a könnyű exploitok kora.