P0: az NSO zero-click iMessage sebezhetőség részletei

1. A célpont iMessage fiókjára küldtek egy gif képnek látszó fájlt, ami valójában egy preparált PDF volt.
    
2. Az iMessage app észlelve a gif kiterjesztést automatikusan meghívta az ImageIO libet egy sandboxban, ami arra szolgált, hogy a kiterjesztéstől függetlenül a fájl tartalma alapján meghatározza a kép formátumát, ezzel azonban több mint 20 képformátum kodekje is támadhatóvá vált.
    
3. A támadáshoz a JBIG2 formátumot választotta az NSO, amit még az 1990-es évek végén fejlesztettek ki, hogy fekete-fehér szkennelt dokumentumoknál kiemelkedően magas tömörítési arányt érjenek el. A formátum szegmensek (~rajzolási utasítások) sorozatából áll, amit a kitömörítés során egymás után végrehajt a kodek, előállítva a végső képet. A szegmenshez tartozó képadatokat (pl. egy karaktert ábrázoló pixelek tömbjét) pedig a JBIG2Bitmap nevű objektum reprezentálja, amely tartalmazza a buffer szélességét (w) és magasságát (h) bitekben, továbbá hogy egy sorban hány byte-ot tárol a buffer (line), illetve egy pointert (data), ami a pixelek bufferjére mutat.
    
4. A konkrét sebezhetőséget - természetesen - egy klasszikus integer overflow adta, ami a szegmensek összeválogatásánál jelentkezett. Az overflow hatására egy alulméretezett buffert allokált a kód a heap memóriában, ahova a későbbiekben JBIG2Bitmap objektumokra mutató pointerek kerültek.
    
5. Megfelelően megválasztva a szegmensek listáját el tudták érni, hogy az alulméretezett bufferbe beírva néhány JBIG2Bitmap pointert, olyan memória-korrupció lépjen fel, hogy az aktív rajzterülethez (oldalhoz) tartozó JBIG2Bitmap objektum h (a buffer magasságára vonatkozó) attribútuma egy ismeretlen, de nagyon nagy szám legyen.
    
6. Mivel a h értékét felhasználta a rendszer a bounds checkingnél is (~milyen memóriaterületre írhat/olvashat egy objektum), ez a pár byte-os módosítás “unbounding” hatással volt az aktív rajzterületre, tehát a következő szegmens már nem csak az eredeti memóriaterülethez fért hozzá, hanem jóval azon túlnyúló tartományokhoz is.
    
7. Ezzel párhuzamosan a heap grooming-nak köszönhetően az aktív oldalhoz tartozó JBIG2Bitmap objektum képessé vált az unbounding után a saját attribútumainak írására. Nem kellett hozzá más, mint 4 byte-nyi bitmap képet renderelni megfelelő koordinátákba, amivel precízen beállíthatóvá váltak a w, h, és line értékek, azaz ezen a ponton már tetszőleges offset előállítható volt.
    
8. A soron következő JBIG2 szekvenciák alkalmas megválasztásával pedig elérhető, hogy csak a kívánt - a formátum által támogatott - logikai operátor (AND, OR, XOR, XNOR) hajtódjon végre (mellékhatások nélkül) a kiválasztott memóriaterületeken. Az unbounding után ez azt jelenti, hogy megfelelő offsetet beállítva a teljes memórián alkalmazhatók a fenti logikai műveletek.
    
9. Habár a JBIG2 formátum önmagában nem szkriptelhető, a fenti logikai műveletek kombinálásával tetszőleges logikai kapu emulálható. Az NSO mérnökei ezt felhasználva összeállítottak egy több mint 70000 szegmensből álló sorozatot, amivel definiáltak egy komplett 64 bites mini számítógép-architektúrát. Mindezt még a kép kitömörítési folyamata közben.
    
10. A támadás soron következő részei már egy magasabb szintű nyelven készültek és ezen a virtualizált architektúrán futottak le.

A következő részben a kutatók azt mutatják be miként jutott ki a program a sandbox környezetből.