Az Adam Gowdiak nevével fémjelzett Security Explorations nyilvánosságra hozta az ún. SE-2012-01 projekt eredményeit. A projekt célja az volt, hogy képet adjon a Java futtatókörnyezetek biztonságáról, és rámutasson a biztonsági architektúrát fenyegető hibaosztályokra. A most közzétett kutatási anyag egyrészt hiánypótló összefoglalást ad a Java biztonsági mechanizmusairól, és bemutat egy sor módszert ezek megkerülésére is.
A kutatás fókuszában a Reflection API állt, ami az alkalmazások futásidejű elemzését illetve manipulálását teszi lehetővé. Mint kiderült, bár az API tervezésekor eredetileg számoltak a biztonsági következményekkel, maga a futtatókörnyezettel szállított csomgok sok esetben veszélyes módon használják ezt a felületet.
(c) Security Explorations - Katt a nagyításhoz!
Az alaprendszer nyilvánosan elérhető osztályai megengedhetik a hívónak, hogy tetszőleges paramétereket adjon át az osztályokon belül használt Reflection interfészekhez. Mivel ezek az osztályok általában kiterjedt, vagy egyenesen korlátlan jogosultságokat biztosító kontextusban léteznek, a Reflection API pedig csak a közvetlen hívó privilégiumait ellenőrzi, egy sandboxból jövő támadó például referenciákat szerezhet biztonsági okokból letiltott csomagok (tipikusan a sun.*) osztályaira és metódusaira, amivel teljes hozzáférést kaphat a virtuális gépen kívüli világhoz. A dolog kicsit hasonlít a parancsinjektálásra, csak itt végül Java bytekód kerül futtatásra.
Ez persze csak egy igen nagyvonalú összefoglaló, az anyag számos különböző exploit technikát ismertet, kezdve a triviálisan kihasználható "Mire kérsz referenciát?" attitűddel megáldott publikus metódusoktól, a hívótól származó adatok szó nélküli deszerializálásán keresztül az XML-ben felépített bytekódokig - mondhatni kötelező olvasmánnyal van dolgunk. Ezen túl a publikáció másokat is megihletett: az Immunity Java szakértője egy hosszabb blog posztban emlékezik meg a Godwiakék munkájának gyümölcseként mostanra már ellehetetlenített, AnonymousClassLoadert alkalmazó exploit technikáról, ezt is melegen ajánlom minden Java hackernek.
(c) Security Explorations - Katt a nagyításhoz!
Az SE-2012-01 érdekes tapasztalatokat oszt meg a különböző gyártók hibajavítási szokásaival kapcsolatban is: A SE az Oracle mellett az Apple és az IBM Java implementációit is vizsgálta, és ezekben is talált problémákat, melyeket jelzett is a gyártóknak.
Az Apple ugyan minden hibát kijavított maximum 5 hónap alatt (valamint egy frissítéssel nem régeltávolította az alapértelmezetten települő saját csomagját a felhasználók gépeiről), de a javítások tényéről nem, vagy csak részben tájékoztatta a felhasználókat (sérülékenység javítás vs. biztonsági megerősítés), a hiba felfedezőiről pedig egyáltalán nem emlékeztek meg és a hibák státuszáról sem tájékoztatták őket. Az IBM ezzel szemben rekordsebességgel (2 hónap) javította a bejelentett problémákat, a feljesztőket pedig rendszeresen tájékoztatta.
Az Oracle-nek pedig most sem sikerült szépítenie: a lomha javítási tempónak köszönhetően a cégnek egy 0-day fenyegetést gyorsjavítással kellett kezelnie, két hibajavítással pedig még mindig adós a válllat. Ezek közül az egyik az utóbbi 10 év összes Java kiadását érinti, a gyártó jövő februárra ígéri a javítást, ami a SE szerint egy 25 karakteres módosítást igényelne, és még integrációs tesztekre sem lenne szükség (bár ezt az Oracle feltehetően másként látja).
Ennek a posztnak kapcsán sem győzöm tehát hangsúlyozni, hogy a Java jelenlegi állpotában egy időzített bomba a munkaállomásokon, amivel szemben sem a rendszeres frissítés, sem a bevett memória-hardening nem nyújt védelmet, az antivírusokról nem is beszélve (az obfuszkálós posztomat egy kollega tovább vitte - kösz a linket axt!). Az SE-2012-01 várhatóan katalizálja majd a kutatást, reménykedjünk benne, hogy ez talán megolajozza egy kicsit a fő szállító óriás fogaskerekeit!
