Tweets by @buherablog
profile for buherator at IT Security Stack Exchange, Q&A for IT security professionals

A BitBetyár Blog

Túljártál a nagyokosok eszén? Küldd be a mutatványodat! (e-mail a buherator gmailkomra jöhet)

Full-Disclosure / Névjegy / Coming out


Promó

H.A.C.K.

Címkék

0day (110) adobe (87) adobe reader (21) anonymous (26) apple (60) az olvasó ír (49) blackhat (20) botnet (22) bug (200) buherablog (44) buhera sörözés (39) bukta (49) deface (38) dns (22) dos (29) esemény (82) facebook (26) firefox (64) flash (33) gondolat (31) google (59) google chrome (36) hacktivity (37) hírek (117) incidens (224) internet explorer (88) iphone (35) java (50) jog (22) kína (21) kriptográfia (68) kultúra (21) linux (24) malware (43) microsoft (142) móka (48) mozilla (23) office (26) oracle (40) os x (43) patch (197) php (20) politika (31) privacy (58) programozás (22) safari (34) sql injection (62) windows (85) xss (77) Címkefelhő

Licensz

Creative Commons Licenc

SE-2012-01

2012.11.25. 15:20 | buherator | Szólj hozzá!

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.

se-2012-01_idea.png
(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.

se-2012-01_oracle_issues.png
(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! 

Címkék: apple java patch ibm oracle immunity se-2012-01 security explorations adam gowdiak

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.