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

Privilegizált kontextusban ne deszerializálj!

2011.03.11. 16:57 | buherator | 7 komment

szerializáció (programozás): egy objektum soros formában (tipikusan karakterláncként) történő megjelenítése

Sami Koivu megint publikált egy sor kellemetlen módszert a Java  applet sandboxból történő kitörésre. Ezek közül kettő a vágólapon található adatokhoz enged hozzáférést viszonylag egyértelmű módon (egy java.swing.TransferHandler-t valamely GUI komponensre helyezve referenciát kapunk a vágólapra), a harmadik viszont az ún. "privilegizált deszerializáció" hibaosztály egy újabb példánya. Ezt a hibaosztályt mutatnám be most néhány mondatban, a cr0 blog vonatkozó bejegyzésére támaszkodva:

Az állítorvosi ló a szintén Koivu által felfedezett, CVE-2008-5353 névre keresztelt hiba lesz, amit az adott évben a legszebb kliens-oldali hibának járó Pwnie-ra is jelöltek. 

A probléma hátterében az áll, hogy az appletekben elérhető java.util.Calendar osztálynak néha deszerializálnia kell sun.util.calendar.ZoneInfo objektumokat. A sun csomag azonban nem hozzáférhető az applet homokozóból alapesetben, de szerencsére (?) a java.util egy megbízhatónak tekintett csomag, amely képes a homokozón kívül is játszani a doPrivileged() blokk használatával. A problémát okozó programrész valahogy így néz ki: 

/**
* Reconstitutes this object from a stream (i.e., deserialize it).
*/
private void readObject(ObjectInputStream stream) {

...

try{
    ZoneInfo zi = (ZoneInfo) AccessController.doPrivileged(
    new PrivilegedExceptionAction() {
        public Object run() throws Exception {
            return input.readObject();
        }
    });
    if (zi != null) {
        zone = zi;
    }
} catch (Exception e) {}

...

}

A gond az, hogy senki sem garantálja, hogy a deszerializálandó soros adatfolyam valóban egy ZoneInfo objektumot reprezentál! A hiba tipikus kihasználási módja az, hogy egy ClassLoader objektumot olvastatunk fel, ami az emelt jogosultságó kontextusban futva tetszőleges osztályt tetszőleges protectionDomain-nel (azaz jogosultsági szinttel) létrehozhat, ezzel pedig vége a játéknak. Az egyetlen bibi, hogy az explicit kasztolás miatt végül mégis történik egy típusellenőrzés, de ekkor már késő, mivel a bemenetként adott objektum readObject() metódusa hozzárendelheti saját magát egy statikus adattaghoz, így hozzáférhető marad, és a szemétgyűjtő sem takarítja el. 

Aki a fentieket elsőre megértette, azoknak ajánlom a család legújabb tagjának áttanulmányozását, ebben az esetben ugyanis még kiegészül néhány elegáns csavarral a történet!

Címkék: java programozás

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.

loolek · http://loolek.tumblr.com 2011.03.12. 07:39:10

@buherator: Pedig be is küldtem, de a szokásos frissitő posztodban és itt se említed meg, hohy ->

Feb 17. megjelent a java 6 update 24 ami bakker, 21 hibát foltozott.

www.oracle.com/technetwork/topics/security/alert-cve-2010-4476-305811.html

Szóval, persze ezt is, a JFileChooser hibát is, a JNLP és webstart problémák stb. mind javítva !!!

Pedig elég precíz szoktál lenni ....

loolek · http://loolek.tumblr.com 2011.03.12. 09:57:11

Az itt is kitárgyalt FPU hibát is javították, véletlenül azt a linket másoltam.

Szóval helyesen Feb. 15. és itt ->

blogs.oracle.com/security/2011/02/february_2011_java_se_and_java.html

buherator · http://buhera.blog.hu 2011.03.12. 10:52:35

@loolek: A poszt nem a Java update-ekről szól.

loolek · http://loolek.tumblr.com 2011.03.12. 11:34:30

@buherator: Hmm, annyit oda írni a végére, hogy a java 6 u24 majdnem egy hónapja már javította, probléma ?!!

Az egy másik topic, hogy a firssítésekről szóló rendszeres posztba miért nem fért be.

buherator · http://buhera.blog.hu 2011.03.12. 12:09:51

@loolek: Még egyszer: ez a poszt nem a Java update-ekről szól.

synapse · http://www.synsecblog.com 2011.03.16. 15:08:40

Loolek hadd válassza már meg buherátor mit hogy posztol. Beszolni meg kulturaltabb privatban.

ja: Tits or GTFO
süti beállítások módosítása