Bár többségük feltehetően nem tud róla, az OS X felhasználók izgalmas napokat élnek mostanában. A Lamadai/Flashback kártevő kifejezetten almás gépekbe próbálja berágni magát Javán keresztül, ami még nem is lenne akkora baj, ha lenne elérhető folt a problémára, de sajnos nincs már van, tegnap (laza 7 héttel a hivatalos folt megjelenése után), mikor kezdtem írni a posztot még nem volt...
A sebezhetőség minden támogatott platformot érint, Windowst, Linuxos ugyanúgy borítani lehet vele, de a frissítés ezekre a rendszerekre február 14-én már elérhető volt. Közben az exploit március 25-én bekerült a zombitoborzó-tisztek közkedvelt BlackHole csomagjába is.
A kihasznált sebezhetőség a CVE-2012-0507 azonosítót kapta, és nagy örömünkre rengeteg információ fellelhető róla a neten. Ezek közül a leginformatívabbak a Metasploit Project vonatkozó commitja (erre lesznek hivatkozások, nyissátok ki új lapon!), valamint a felfedező Jeroen Frijters saját leírása, a hibás típusegyeztetésből adódó Java sérülékenységeket pedig remekül összegzi ez az oldal.
A sebezhetőség lényege az, hogy az AtomicReferenceArray objektumokban el lehet tárolni A típusú elemeket, majd ki lehet olvasni ezeket B típusúként, anélkül, hogy a futtatókörnyezet értesülne a csalásról. Frijters példájával:
AtomicReferenceArray ara = new AtomicReferenceArray(new Integer[1]);
ara.set(0, "foo");
Integer value = (Integer)ara.get(0);
A value ekkor egy Integer típusú(nak hitt) String objektumot tartalmaz.
Az Exploit osztályban található as tömb egy szerializált Java objektum, ami a 39-40. sorban deszerializálódik. Ha rámegyünk debuggerrel erre a részre, ezt kapjuk:
Amint látható, egy objektum tömbről van szó melyben egy AtomicReferenceArray és egy Help objektum (tömb) szerepel. A Help a támadó által definiált osztály, a ClassLoader leszármazottja. A ClassLoader osztály védett defineClass() metódusa lehetővé teszi tetszőleges jogosultsággal rendelkező osztályok létrehozását, mivel azonban ezt a metódust nem lehet megbízhatatlan kódból hívni, vagy az osztályt példányosítani, ezért ezzel egyelőre nem sokra megyünk.
A 42. sorban példányosítjuk az AtomicReferenceArray osztályt, méghozzá a fent említett szerializált állapotból. Erre azért van szükség, mert az AtomicReferenceArray-ba kerülő objektumok egy Object[] típusú attributumban kerülnek tárolásra alap esetben, a szerializáció azonban lehetővé teszi, hogy ennek az adattagnak más típust, ebben az esetben Help[]-et adjunk, másrészt a tárolt tömb referenciájára még szükségünk lesz a későbbiekben. Az as-ból visszahozott aobj tömb első AtomicReferenceArray típusú eleme valójában a nulladik Help[] objektumra hivatkozik vissza az array adattaggal.
A trükk a 44. sorban következik, amikor is az atomicreferencearray nulladik (Help típusú) elemének az Exploit osztály Applet ősétől kapott ClassLoader-ét allítjuk be. Erre az objektumra van egy referenciánk ahelp néven, amiről a futtatókörnyezet azt hiszi, hogy Help típusú, de valójában egy ClassLoadert tartalmaz. Ezt a referenciát átadhatjuk a Help.doWork() statikus metódusnak. Mivel a futtatókörnyezet azt hiszi, hogy a Help.doWork() egy Help típusú objektummal dolgozik, meg fogja engedni a védett defineClass() hívását, ami azonban nem egy Help, hanem az Applettől kapott ClassLoaderen fog lefutni, jogosultan tetszőleges biztonsági beállítások meghatározására. Ezzel vége a játéknak.
Friss: A Dr.Web eddig 600.000 fertőzött Mac-et számolt össze, ebből 274-et Cupertinoban
