Ma reggel egy vadiúj Java 7-et érintő 0day exploitról érkeztek hírek. A problémát az ok.aa24.net-en jelenleg is aktívan kihasználják kártékony kódok terjesztésére. Mint minden jóra való Java exploit, ez is igen megbízhatóan működik tetszőleges platformon, az Oracle következő frissítése viszont csak október közepére van betervezve. Az egyetlen jó hír, hogy a probléma csak a JVM 7-es változatát érinti, tehát a 6-os verzióra történő visszaállás segít a problémán. Az OpenJDK érintettségével kapcsolatban egyelőre nem találtam információt.

A Metasploit projekt 24 órán belül portolta az exploitot a keretrendszerbe, így most már bárki tesztelheti a rendszereit a sérülékenységgel szemben. Maga a kód meglepően egyszerű, és bár részletes elemzést nem láttam nálam okosabbaktól, ha jól látom arról van szó, hogy a java.awt.SunToolkit.getField() privilegizált környezedben hajlandó kikapcsolni bármelyik objektum bármelyik mezőjén a Java hozzáférésellenőrzését, így egy Applet számára elérhetővé tehető a System.setSecurityManager() amivel beállíthatjuk, hogy a távoli szkript a helyi megbízható programoknak megfelelő jogosultságokat kapjon.

Axtaxt jobban érzi a Java-fu-t:

Egészen pontosan az történik, hogy az exploit kreál egy java.beans.Statementet ami execute() esetén a "setSecurityManager(null)"-t hívja. Ez azonban SecurityExceptionnel elszállna, ezért az AccessControlContextjét felülírják egy az az exploit által definiálttal (AllPermission). Ehhez van szükség a sun.awt.SunToolkit osztály getField függvényére, ami elvégzi privilegizált környezetben a setAccessible(true) hívást a kívánt fieldre, hogy így már reflectionnel könnyen megtehető legyen az AccessControlContext felülírása. Viszont a "sun.awt.SunToolkit"-re alapból nem tudnánk class referenciát szerezni appletből, mert az applet security managere ezt nem engedi, hiszen az osztály a "sun.*" csomag része. Ezt viszont egy elegáns new Expression(Class.class, "forName", new Object[] {"sun.awt.SunToolkit"}).invoke() hívással mégiscsak sikerül megoldani.

Ha jön még infó, frissítem a posztot, addig is kapcsoljátok ki a Java-t, vagy legalábbis váltsatok 6-os főverzióra (ez nem biztos hogy tartós megoldás lesz, lásd a frissítést!), esetleg próbáljátok ki a Deep End Research foltját!

Friss:

A Deep End Research is publikálta a sérülékenység részleteit. Michael Schierl szerint a problémát egész konkrétan a sun.beans.finder.ClassFinder osztály helytelen megvalósítása okozza, ez teszi lehetővé a tiltott csomagokhoz történő hozzáférést. Az exploitnak ezen túl meg kell oldania azt is, hogy a byte kód ellenőrző ne kezdjen visítani, ha meglátja az appletben a sun csomagra történő hivatkozást, erre nyújt megoldást a Statement osztály használata - nem mellesleg, reflectionnel egy csomó víruskergető is átvágható. A cikk szerint Java 7-nél korábbi változatokon a SunToolkit.getField() még privát metódus volt, ezért nem megy az exploit, a ClassFinder problémája más tiltott osztály közreműködésével is kihasználható lehet! 

Friss2:

A MITRE a CVE-2012-4681 hibajegyet rendelte a sérülékenységhez. Egyes biztonsági cégek állításával szemben jó eséllyel nem célzott támadásokról van szó.

Friss3:

Java6u34-el tesztelve az exploit már a Class.forName("sun.awt.SunToolkit")-nél hozzáférési kivételt dob, ez jó hír a 6-os verziót futtatók számára.

Friss4:

Kicsit keveset vagyok netközelben mostanság, néhány gyors infó:

• Részletes elemzés a kihasznált hibákról (igen, több is van) itt olvasható, ebből lesz részletes poszt kis Java security 101-al megspékelve - izé, most látom, hogy már van egész jónak tűnő magyar nyelvű anyag (bár a víruskergetőkre én sem bíznám rá magam...)
• Az Oracle állítólag április óta tudott a problémáról és nem lépett
• OS X-es kártevők terjednek a hiba kihasználásával
• Az exploitot beemelték a Blackhole Exploit Kit-be
• Az Oracle kiadta a hivatalos javítást, melyben 4 hibát javítottak, a patch elemzésével további sandbox kitörési módszereket kapunk
• Az OpenJDK-t illetve az IcedTea-t is frissíteni kell!