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!
loolek · http://loolek.tumblr.com 2011.03.12. 07:39:10
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
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 · http://loolek.tumblr.com 2011.03.12. 11:34:30
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
synapse · http://www.synsecblog.com 2011.03.16. 15:08:40
ja: Tits or GTFO
_2501 2011.03.16. 15:36:36
érzed? :D