Názory k článku
Bezpečnostní díra v Java knihovně ohrožuje stovky aplikací

Ne, nepíše. Podívejte se na ten odkazovaný článek – WebLogic je napaden přes protokol T3, OpenNMS přes RMI…

Vy jste tím webem nějaký uhranutý, ne? Asi jste myslel, kdo má T3 nebo RMI „vystrčené do veřejného internetu“. No tak někdo to tak mít může, vždyť jsou ty přístupy chráněné autorizací a mělo by to být bezpečné. A i když to někdo má přístupné jenom z nějaké privátní sítě, pořád není správné, že kdokoli v té síti může ten server třeba vypnout.

Apache reverse proxy je snad minimum co tam ludia davaju
Soudní lidé tam Apache reverse proxy nedávají.

Diera to je, netvrdim ze nie, ale nie taka velka ako sa snazi autor exploitu naznacit.
To spíš záleží na konkrétní situaci. Horší podle mne je, že ta díra spočívá v něčem jiném, než autoři exploitu naznačují, a hlavně že ten jejich „fix“ zalepí jednu konkrétní díru, kterou zkouší jejich exploit, ale neřeší tu díru jako takovou.

Load balancing a fail over riesite ako?
No tak konkrétně my to řešíme hardwarovým loadbalancerem. Ale některé aplikace jsou rozvažované na úrovni TCP spojení, takže to má hodně blízko k tomu, kdyby ten WebLogic byl přímo vystrčen do internetu?

Ci pouzivate WebLogic za velke peniaze a mate ho rovno vystrceny do internetu?
Bojíte se, aby se neošoupal? Já teda tak nějak u dražšího řešení předpokládám, že by mělo být lepší a tudíž i bezpečnější.

Jinak já jsem narážel na to, že když tak autoritativně zmíníte jedno řešení v situaci, kdy jich existuje n různých podle konkrétních požadavků, nepůsobí to dojmem znalce, o což jste se asi snažil, ale právě naopak.

Diera tam ziadna nie je. Iba niekto zle implementoval deserializaciu udajov.
Jo, a když někdo zadá příjmení „Novák'; drop database;“, tak to také není chyba ale jen „zle implementovaná deserializacia udajov“.

Oni spravili kod v custom deserializacnom hooku ktory robi neplechu, to nie je genericka diera.
Přečtěte si popis té chyby, je to hned druhý příspěvek v diskusi. Ta třída, která v rámci deserializace spouští neznámý kód, je součástí JRE. To je dost generické. A takových tříd, které nemají readObject() odolný proti útokům, bude spousta. Spuštění kódu, který útočník nikdy neměl mít možnost spustit, je docela průšvih. Samozřejmě by mohl být ještě větší, tady má útočník přeci jen omezené možnosti – vedle té třídy s readObject() potřebuje další vhodné třídy, přes které útok povede (např. ty z Apache Commons Collections).

Jo, a když někdo zadá příjmení „Novák'; drop database;“,
Myslel jsem samozřejmě případ, kdy vám tím smaže databázi.

To, že jste něco neviděl, neznamená vůbec nic. A vzhledem k tomu, co tu píšete v komentářích, to neznamená tuplem vůbec nic.

Pro útočníka zajímavé metody poskytuje i standardní knihovna, třeba System.exit nebo Runtime.exec. K tomu, že útočník může smazat databázi, i když v programu žádný takový kód není – hledejte pojem „SQL injection“. Když má útočník v ruce spojení do databáze a může na něm zavolat libovolný příkaz, má dost silný nástroj.

To HTTP a web vás opravdu uhranulo. Vězte, že existují i jiné síťové protokoly, než HTTP, a také se přes ně dají přenášet serializované objekty. A dokonce může útočník podvrhnout serializované objekty i do vstupu, který server nedostane síťovým protokolem, ale třeba ze souboru nebo databáze.

To nevím, co s tou vaší paranoií budete dělat, až zjistíte, že existují i jiné protokoly než HTTP. SQL injection jsem uváděl jako příklad toho, co může útočník udělat, pokud dokáže zneužít téhle chyby. Byla to reakce na vaše tvrzení, že je ta chyba nezajímavá, protože útočník nemůže spustit žádný jiný kód, než ten, který je v aplikaci. Pouze dodržování zásad k zajištění bezpečnosti nestačí – je potřeba tomu také rozumět. Jinak dotyčný dopadne jako vy a bude si myslet, že když používá binding parametrů, nemusí se SQL injection bát.

Zranitelné jsou, pokud mají přístupný port, na kterém běží služba používající problematickou deserializaci.
Důležité také je, zda k té deserializaci dochází před autentizací uživatele, případně zda se rozlišují úrovně oprávnění, nebo pokud je komunikace nešifrovaná a útočník ji může pozměnit (což by ale byl větší problém, než ta deserializace). Pokud je ta problematická služba určena pouze pro administrátory, není to kritické – pokud administrátor sám sobě úmyslně shodí server, je to jeho chyba, a má k tomu ostatně mnoho jiných příležitostí, než hackovat deserializaci.

Ověřit to lze, přímo původní článek obsahuje HOWTO i odkaz na repozitář s exploit kódem.
Vzhledem ke zmatenosti toho příspěvku oznamujícího chybu bych byl velmi opatrný při spouštění kódu, na který ten příspěvek odkazuje.

No, to by mne také zajímalo. Ta chyba teoreticky existovat může. Knihovna Apache Commons Collections by v takovém případě vystupovala spíše jako nástroj útoku než jako zdroj té bezpečnostní chyby. Každopádně ten odkazovaný popis je velmi zmatený a nepopisuje samotný princip chyby, to by se muselo zjistit reverzním inženýrstvím toho exploitu. Existují už nějaké záplaty k té chybě (třeba pro Groovy), takže reálný základ to asi má. Ale nevím, jestli už existuje nějaký seznam tříd, které jsou k téhle chybě zneužitelné.

Správné řešení tohohle problému spočívá v tom, že nemůžete deserializovat třídu podle názvu, který vám mohl někdo podstrčit, ale vždy musíte při té deserializaci předem vědět, jaký typ objektu (nebo typy) očekáváte a musíte kontrolovat, že někdo nepodstrčil něco jiného.

Každopádně chyba je zneužitelná jenom tehdy, pokud má útočník možnost podvrhnout serializovaná data, tedy typicky pokud jde o klient-server aplikaci, kde klient předává serveru objekty serializované pomocí Java serializace – tedy ne třeba přes XML nebo JSON (ale pozor na to, že ty serializované objekty klidně mohou být přenášené třeba přes HTTP).

Chytřejší útočník samozřejmě nepodstrčí náhodně zvolené jméno, ale jméno třídy, kterou je možné přiřadit do příslušného typu. Uváděl jsem příklad s Runnable, případně třídy, které pracují s reflexí. Samozřejmě, možnosti útočníka jsou celkem omezené a nemůže volat vlastní kód, ale jen kód, který už je přítomný v aplikaci.

Teď už zbývá jenom vysvětlit rozdíl mezi „deserializovaná data“ a „klasické vstupy“.

Uživatel se k serializovaným datům vůbec nemá dostat!
V tom případě ale nemůžete spouštět aplikaci na počítači uživatele. Nebo-li tu aplikaci nebude moci nijak používat. Třeba i webová stránka jsou serializovaná data uživatele. Je potřeba rozlišovat mezi obecným termínem serializace, a standardní Java serializací založenou na rozhraních java.io.Seria­lizable a java.io.Exter­nalizable. Podobnou chybu samozřejmě mohou mít i jiné způsoby serializace, ale serializace do webových stránek a formulářů takovouhle chybu nemá.

Problém ve skutečnosti není v tom, že jsou serializovaná data u uživatele, ale v tom, co se s nimi při deserializaci provádí. Pokud deserializujete jenom hodnoty datových entit, problém v tom není a musíte na serveru hlídat akorát to, že je datový typ správný, má správný rozsah a případně splňuje další požadavky (rozsah hodnot apod.). Problém je, že při standardní Java serializaci se serializuje i jméno třídy, takže útočník může podstrčit instanci jiné třídy se stejným rozhraním, která je k dispozici na classpath, a pokud se pak provede na té deserializované instanci kód, provede se na té neočekávané třídě (tedy pořád je to kód, který je na serveru, nemůže si útočník podstrčit svůj – ale může to být kód, který v daném kontetxu nikdy neměl být volán). Další možnost je, že by se serializovaná data načítala přímo jako bajtkód, ale to snad nikdo soudný neudělá (už jenom proto, že vnutit do JVM přímo z aplikace svůj bajtkód není úplně triviální, a pokud to někdo dělá, tak snad ví, co dělá).