Elég sok érdekes információ jelent meg az aktuális, javítatlan Java sérülékenységgel kapcsolatban - ezek egy részéről az előző poszt alatt a kedves Olvasók is megemlékeztek (köszi!) ebben a bejegyzésben igyekszem összegyűjteni a legfontosabb tudnivalókat és hivatkozásokat.

A legrészletesebb elemzést a sérülékenységről az Immunity szolgáltatja. Ebből megtudhatjuk, hogy a most kihasznált sérülékenység nagyon hasonlít a tavaly augusztusban észlelt támadásokban kihasználthoz, illetve a Security Explorations által tárgyaltakhoz:

Egy, a Reflection API-t nem biztonságos módon használó osztályon (ezesetben a com.sun.jmx.mbeanserver.MBeanInstantiator osztály findClass() metódusán) keresztül referencia szerezető bármilyen, elméletileg korlátozottan elérhető osztályra, majd a Reflection API hibáját kihasználva az osztály metódusai is meghívhatók - a sikeres kódfuttatáshoz tehát két hiba összekapcsolása szükséges.

A vicc az, hogy a második problémát az Oracle elvileg már az előző fiaskó után javította. Elvileg. Annak idején is a MethodHandle.invokeWithArguments() okozta a bajt azáltal, hogy nem ellenőrizte megfelelően a hívó Class Loaderét, így  reflection-ön keresztül hívva hajlandó volt bármely osztály bármely metódusát meghívni, mivel a reflection API osztályai megbízható (NULL) CL-el rendelkeznek. A gyártó úgy igekezett orvosolni a problémát, hogy a valódi hívó felkutatásakor kihagyta a régi reflecion API hívásait, magával az új Reflection API-val ugyanakkor nem számolt a javításkor, a probléma így kihasználható maradt: "egyszerűen" a Reflection-t is Reflection-nel kell hívni.

Mivel az új Reflection API Java 7-től van jelen, ez a kihasználási út csak a futtatókörnyezet említett főverzióján működik, az MBeanInstantiator viszont legalább a JDK 6u10-től kezdve sérülékeny. Ilyen esetben kicsit nehéz az egyszeri tanácsadó dolga: ugyan a 7-es főverzió már hasznos biztonsági feature-ökkel rendelkezik, a vadon tenyésző exploitok mégis csak ezt a családot támadják - én jelenleg úgy gondolom hogy a Java 7 biztonsági szintjének "Nagyon magasra" állítása jó kompromisszum lehet a használhatóság és a biztonság között (ha az ember nem játszik céllövöldét az "Engedélyezés" gombbal).

További segítséget jelenthetnek a Mozilla és az Apple megoldásai, melyek a Chrome példáját követve alapértelmezetten megerősítéshez kötik ileltve letiltják az appletek futtatását a Firefox illetve Safari böngészőkben. Itt hangúlyoznám, hogy - bár a támadások egyelőre Windows felhasználók ellen irányulnak - a sérülékenységek triviálisan átültethetők bármely Java appleteket futtatni képes platformra ide értve OS X-t és Linux-t is (OpenJDK érintettségéről eddig nem láttam infót, ezügyben kiegészítést szívesen vennék).

Az Oracle azt ígérte, hogy "rövidesen" (agyameláll) kiadják a biztonsági frissítést a problémára. Bár a cég tavaly év végén elvileg ígéretet tett arra (Oracle link), hogy a Java-t is a többi termékkel, évente minimum négy alkalommal fogja frissíteni, a hivatalos oldal jelenleg 3 Java CPU-t jósol, a következőt február közepére. A többi termék jövő kedden kap javítást, azonban ez a csomag az előzetes értesítő szerint sem fogja érinteni a Java-t.

Friss (jan. 14 10:00): Az Oracle rendkívüli javítást adott ki a problémára, ezen kívül alapértelmezetten Magas-ra emelte a Java 7 futtatókörnyezetek biztonsági szintjét - ez azt jelenti, hogy az aláíratlan/önaláírt appletek nem futnak alapértelmezetten. 

Friss (jan. 14 10:55): A Security Explorations pontosította az Oracle korábbi frissítéséről szóló elemzését.