Javocalypse - "az utolsó szög kell legyen a Java appletek koporsójába"

Bug

Julien Tinnes, a Google biztonsági csapatának tagja - tegnapi blogbejegyzésében arról ír, hogy Sami Koivu egy évvel azután, hogy egy rakás Java-val kapcsolatos biztonsági hibát hozott napvilágra, újra egy csokor buggal jelentkezett. De nem csak Koivu, hanem Tinnes kollégája, Tavis Ormandy is érdekes felfedezésekkel állt elő. Tinnes szerint ez már az utolsó szög kell legyen mindenkinél a Java appletek koporsójába, akinek biztonsággal kapcsolatos elvárásai vannak. Tinnes a következőket javasolja azoknak, akik nem akarják, hogy rommá törjék:

  • a Java letiltása a böngészőkben
  • Windows-on a Java teljes eltávolítása (nem elég a letiltás) vagy Tavis workaround-jainak alkalmazása

Tinnes egy kérdésre válaszként a kommentekben megjegyzi, hogy a CVE-2010-0095 ID-vel rendelkező bugon kívül minden, a blogbejegyzésben említett hiba tetszőleges kódfuttatáshoz vezethet.

A részletek a blogbejegyzésben. A Tavis Ormandy által talált hibáról bővebben itt.

( sz332 v | 2010. 04. 10., szo – 14:51 )

Érdekes dolgokat írnak a következő blogon:

http://slightlyrandombrokenthoughts.blogspot.com/

Valójában nem Java-val kapcsolatos problémák ezek, hanem a Sun JRE-ben talált bugok, illetve kellően végig nem gondolt "fejlesztések" (ez nem bug, hanem feature:))

Jó részükre már van is javítás.

"Updating Java does not work, Sami has already mentioned that he would be very surprised if there weren't 10 other cases of "Java trusted method chaining" bugs. There are probably other deserialization ones too."

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

"...And anyway, a lazy attacker can just silently downgrade his up-to date target to whatever vulnerable Java version he wants to exploit, using the aforementioned Java deployment toolkit. Really, it's a feature".

az OpenJDK/icedteaből viszont sok feature hiányzik még, így nem tökéletes a kompatibilitása sem. ezért kérés. a hátrány ebben az esetben előny lehet.

( Dwokfur v | 2010. 04. 10., szo – 18:47 )

Az ilyen sebezhetőségeket nem fogja meg egy unsecure garbage collector? ;>

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( tr3w v | 2010. 04. 10., szo – 20:39 )

Hmmm... Ezek szerint nem csak a Flash szar és nem csak az Adobe-nál nem tudnak programozni... :)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

( KGer | 2010. 04. 10., szo – 21:03 )

Azert a Java VM-et nem kene ennyire leszolni, tizenX eves technologiai forradalom es meg ma is siman megallja a helyet.
Vannak benne sechole-k, remeljuk majd javitjak.

Az applet-ek valoban nincsenek elterjedve, de ha jol tudom meg az oracle elott voltak ez ellen komolyabb erofeszitesek JavaFX neven. Egyebkent meg az applet-et sohasem reklamoknak meg vicces animacioknak szantak, hanem olyan komolyabb felvastag klienseknek, amikhez mar keves volt a html+javascript+tarsai, es ha jol tudom ezen a teren meg mindig vezet.

( _Franko_ v | 2010. 04. 10., szo – 22:23 )

Hm... elolvastam. Javítsatok ki, ha rosszul értelmezném, de azt látom, hogy a JavaWebStart alkalmazásokról van szó, amelyek ugye nem appletek. Továbbmenve azt olvasom, hogy a böngészőt futtató felhasználó jogaival tud futni bármi, ezáltal a szerver gazdája képes a felhasználó jogaival bármit tenni-futtatni a gépen. Jól értem?
--
http://wiki.javaforum.hu/display/FREEBSD

Az összesben arról van szó, hogy az user megnéz egy káros kódot tartalmazó weboldalt, ott elindul egy applet vagy egy JavaWS, majd az user kattint a "megbízom az applet/JavaWS aláírójában" ablakon, hogy megbízik benne, majd elindul a különféle kiskapukat kihasználó kártékony kód.

Van egy kapu, Tavis és társai nagyítóval keresnek olyan lehetőségeket, amelyekkel be lehet jutni, éppen azon vitáznak, hogy ha három méteres drótot megfelelően hajlítanak, és bedugják azt egy apró résen, akkor be tudnak-e jutni vagy sem, amikor jön az egyszerű felhasználó, megnyomja a kivilágított "Ajtó nyitása" gombot, és a kinyíló az ajtón besétál.

Mit nem tudsz végrehajtani egy JavaWS programmal, amelyhez távolról be kell töltened egy natív kódot? Amint a felhasználó elfogadja, hogy a JavaWS programban megbízik, attól a ponttól kezdve az a JavaWS program olyan, mintha helyben indította volna el. És bármit meg lehet csinálni így, amire van a felhasználónak joga.

Ennek az a háttere, hogy aláírás nélküli applet vagy JavaWS valóban sandbox-ban fut, amiból nehéz kijutni. Egy aláírt applet vagy JavaWS _önmaga_ határozza meg, hogy milyen kiutat kér a sandbox-ból, ami általában az szokott lenni, hogy mindent kér, amit egy helyben indított Java program megkap, a felhasználó meg mindig elfogadja ezt. Az aláírás lehet self signed is, nem számít, egyel több megnyomandó "Ok" gombot jelent, ezért minden applet és JavaWS alá van írva, és mindenre jogot kér.

Ps.: a második linked javítva van az Java6u19 kiadásban.
--
http://wiki.javaforum.hu/display/FREEBSD

Probléma van, de azt nem látom, hogy széles körben kihasználható lenne-e, nem láttam még olyan széles körben használt appletet vagy JavaWS programot, amely ne lett volna aláírva és nem kért volna meg minden jogot. Ettől kezdve pedig az a biztonsági hiba, amely az aláírás nélküli appletek sandbox-ból való kijutását segíti elő bizonyos feltételek között: eléggé kis súlyba kerül. Például Tavis által közölt JVM lecserélés csak úgy tud előállni, ha az user gépén van a lecserélt dll, vagy egy számára elérhető Windows megosztáson le tudja tölteni azt... egy self signed JavaWS pedig akárhonnan letölthet akármit és elindíthatja azt.

Ha például megnézed a http://likj.javaforum.hu/likj.jnlp linket, itt el fog indulni egy JavaWS program, kérdezni fog, elfogadod, attól kezdve a programnak joga lesz a File/Select work folder... alatt meghatározott könyvtárba írni, ám nincs a jogkérés ilyen szinten szabályozva, egyszerűen tudnék letörölni mindent, amire jogot adtál a gépeden, le tudnék tölteni bárhonnan bármit és el tudnám azt indítani egy sima Runtime.exec hívással.
--
http://wiki.javaforum.hu/display/FREEBSD

( srrrgei | 2010. 04. 12., h – 19:31 )

OpenJRE-vel többször tapasztaltam olyat, hogy egy GUI alkalmazás elindul, és egy üres ablakot ad. Ilyen például a Maple. Sun JRE-vel tökéletesen megy. /sorry, félrement/

( tzp | 2010. 04. 16., p – 15:27 )

Én megnéztem a teszt oldalt a cikk alapján (http://seclists.org/fulldisclosure/2010/Apr/119 ) itt:
http://lock.cmpxchg8b.com/bb5eafbc6c6e67e11c4afc88b4e1dd22/testcase.html , módosítottam linuxosra az exec-et a jar-ban, de nem működött, az "install missing plugins" jött fel, pedig működik a Java pluginom.

Csak tippelek, ez azért van, mert nincs beállítva mime kezelő ezekre ?:

o.type = "application/npruntime-scriptable-plugin;deploymenttoolkit";
n.type = "application/java-deployment-toolkit";

Azt mi állítaná ez be, melyik plugin ? A java (1.6.0_18 libnpjp2.so) nem kezel ilyet.
Talán lemaradtam valamiről ?
(bár írta, hogy Linuxon neki sem sikerült a dolog, mármint ez a lap: http://www.reversemode.com/index.php?option=com_content&task=view&id=67… )