Oracle uvolnil aktualizaci Javy opravující 50 zranitelností

cekal bych, ze spise vydaji aktualizaci, ktera jednou provzdy odstrani ten bastl ze systemu a zabrani pokusum o jeho instalaci

/ironie/ Náhodou, já nevím co proti té javě všichni mají, vždyť se s ní dá udělat naprosto všechno. Zrovna nedávno jsem narazil na takový pěkný javový instalátor ovladačů pro USB modem. Jen nechápu, jak mohl zákazník vůbec používat počítač když neměl žádnou javu nainstalovanou a navíc ani přístup na web.

Více mě sere KB. Jen jsem si ulevil. Proč KB nedetekuje Javu a všude jinde funguje?

Online bankovnictvi KB MojeBanka totiz preferuje Javu od Oracle a v Linuxu ten plugin do Firefoxu je potreba nalinkovat do adresare plugins (nebo extensions, ted nevim).

Kdyz opravu hned nevydaji (nejspis proto ze to resi na vic mistech) je to spatne, kdyz ji vydaji, je to zase spatne... Kdyby nebyli blbi najali by si vsechny ty python a php odborniky z diskuzi a jejich problemy by zmizely mavnutim carovneho proutku...

No ja bych rekl, ze vydavat aktualizaci az kdyz se nasbira 50 zranitelnosti je snad trochu pozde...

Je to 50 uplne ruznych zranitelnosti, nebo je to 50 zranitelnosti reknime stejneho typu na ktere prisli temi proflaknutymi 2-3? Myslis, ze si opravdu rikali ze posetri svoje download servery, a pockaji az se jich nazbira 50, at to lidi netahaji na 5x?

To budou mít zákazníci Komerční banky jistě radost! :) Nechápu proč v KB používají Javu, třeba Česká Šiditelna vyžaduje pro Servis24 jen prohlížeč a jede i bez balastu!

Tak je to z historických důvodů. KB spustila online bankovnictví někdy počátkem století (200něco málo - nechce se mi hledat). A bankovnictví bylo od počátku moderně technicky navrženo (asymetrické šifrování, přihlašování pomocí certifikátu, který mohl být jak v souboru, tak v HW zařízení). A bankovnictví bylo funkčně velmi silné. Tohle tehdy neměl v Česku skoro nikdo. Výjimkou byla jenom e-banka, která byla ale zvláštní případ, protože internet považovala za svůj hlavní kanál a měla to štěstí, že byla velmi mladá (tedy si netáhla za sebou žádnou historickou kouli na noze).
Zrovna spořka byla (a pokud ji někdo používá, tak může napsat, jestli stále je) v tomhle jako z jiné planety - žádný certifikát (jenom uhádnutelný login + heslo). Asymetrické šifrování v začátcích rozhodně nepoužívala. A funkcionalitami to byla ve srovnání s KB bída.

A za tahle velká pozitiva se u KB se platila dvojitá daň: IE only aplikace a obsluha kryptografie v javě. Jako bonus máte, že si HTTPS kanál (nebo důležité informace v něm) můžete přešifrovat ještě jednou a případná chyba v aktuální verzi/implementaci SSL pro vás není tolik kritická.
Chápu KB, že pro ně bylo snadnější nahradit existující webový front tou javascriptovou zběsilostí, co tam teď mají, než předělat kryptografickou vrstu do javyprostého stavu.

Moje zkušenosti jako webového vývojáře nejsou valné, takže mne klidně opravte, ale jak chcete zodpovědně a bezpečně naimplementovat klientskou stranu asymetrického šifrovacího kanálu? Dříve byly dvě možnosti: ActiveX a Java (a KB zvolila tu jednoznačně lepší variantu). Jak je to dneska? Na klientské straně přece jenom musíte vykonat celkem dost kódu, takže jak se to má dneska dělat správně bez javy (nebo nějaké javy v bleděmodrém)? Poučte mne webáci.

Otazka zni, proc to vubec delat.
a) jestlize nekdo ma read only pristup tak se nic moc nedeje, v nejhorsim nekdo prijde na to ze nekdo neco vytuneloval
b) jestlize potrebuje nekdo vyssi stupen bezpecnosti, tak prihlaseni+jed­norazove heslo krz sms by melo stacit

By mělo stačit - co to je za odpověď? Na co by to mělo stačit?

Zajímavé je, že když dojde na platební karty, tak jsou všichni paranoidní na druhou a nejvíce se cení karty, ke si mohu telefonem stahovat limity na nulu a kartu úplně zamykat (a limity zvedat a odemykat jenom na chvíli na tu konkrétní transkaci). Tedy ne všichni pochopitelně, to je nadsázka, ale jsou takovýchto lidí plné diskuze.

A na druhou stranu, když se jedná o bezpečnost internetového bankovnictví, tak tam principiální rozdíly v bezpečnostních mechanismech neřeší nikdo. Tedy až na určitou skupinu lidí, která to vidí tak, že bezpečnost = autentizační kalkulačka a když kalkulačka není, tak je to jedno.

„Zajímavé je, že když dojde na platební karty, tak jsou všichni paranoidní na druhou a nejvíce se cení karty, ke si mohu telefonem stahovat limity na nulu a kartu úplně zamykat (a limity zvedat a odemykat jenom na chvíli na tu konkrétní transkaci).“

Strawman.

„A na druhou stranu, když se jedná o bezpečnost internetového bankovnictví, tak tam principiální rozdíly v bezpečnostních mechanismech neřeší nikdo.“

Já žádný principiální rozdíl mezi Java nesmyslem, který mi načte soubor s certifikátem, a prohlížečem, který mi načte soubor s heslem, nevidím.

„Tedy až na určitou skupinu lidí, která to vidí tak, že bezpečnost = autentizační kalkulačka a když kalkulačka není, tak je to jedno.“

Ale KB nevyžaduje Javu (jen) pro kalkulačku.

Uf a co je tohle za odpoved?

Neznam bankovnictvi ktere by v pripade ze nepouziva nejakou kalkulacku atd nepotrebovalo mobil... Tak o cem tu tocis. Kdyz nekdo chce fraudnout gazilion penez tak ti kyjem zlomi nohu a ty mu rad jeste podekujes ze si ty prachy vzal...

Vyzivat se v prehnane bezpecnosti ktera komplikuje zivot misto aby pomahala je trosku nizke...

„KB spustila online bankovnictví někdy počátkem století (200něco málo - nechce se mi hledat).“

A tehdy neexistovalo HTML? :-O

„A bankovnictví bylo od počátku moderně technicky navrženo (asymetrické šifrování, přihlašování pomocí certifikátu, který mohl být jak v souboru, tak v HW zařízení).“

Prosím, popište mi nějaký útok, kterému má tohle zabránit.

„A bankovnictví bylo funkčně velmi silné.“

Nemyslím si, že by tam bylo něco, co by nešlo napsat v čistém HTML + JS roku 2001. V IE5 určitě chodily rozličné „interaktivní“ věci. Ale i tak, proboha, je rok 2013.

„žádný certifikát (jenom uhádnutelný login + heslo)“

Jak se v tomto případě liší uhádnutelné heslo od uhádnutelného certifikátu?

„Asymetrické šifrování v začátcích rozhodně nepoužívala.“

Počkat, „asymetrickým šifrováním“ myslíte SSL? Nebo co si pod tím mám představit?

„Moje zkušenosti jako webového vývojáře nejsou valné, takže mne klidně opravte, ale jak chcete zodpovědně a bezpečně naimplementovat klientskou stranu asymetrického šifrovacího kanálu? “

Asymetrické šifrování běžně používá můj prohlížeč kdykoli přistupuji na nějakou stránku přes HTTPS.

>A tehdy neexistovalo HTML? :-O

Pěkný trolling.

>Prosím, popište mi nějaký útok, kterému má tohle zabránit.

Snadnému odposlechnutí jména+hesla. Případně zneužití šifrovacího klíče na straně banky. Ale to jsou základní věci. Když je nevíte - v pořádku - ale je nutné se ptát na základní věci stylem, jako že jste mistr světa?

>Nemyslím si, že by tam bylo něco, co by nešlo napsat v čistém HTML + JS roku 2001. V IE5 určitě chodily rozličné „interaktivní“ věci. Ale i tak, proboha, je rok 2013.

Na RIA funkčnosti používal tehdy Javu nebo ActiveX skoro každý. Kromě těch, kteří opravdu potřebovali, aby to fungovalo bez těchto doplňků, ale potom to většinou nebylo tak moc rich. Takže bych neřešil, že "nějak to určitě jít muselo". Už jsem psal, že tady nejde o nějakou interaktivnost - jde o jejich implementaci bezpečnosti. A to - jak už jsem psal - není tak snadné napsat jinak - a navíc je otázka, jestli to vůbec jinak jde. To byla moje otázka na začátku - jak danou věc implementovat bez javy. Od vás, ani od jiného jsem se to zatím nedozvěděl.

>Jak se v tomto případě liší uhádnutelné heslo od uhádnutelného certifikátu?

Certifikát není na úrovni hesla, ale na úrovni loginu. I tak je jeho bezpečnost vyšší, než je obvyklá bezpečnost hesla. A to vůbec nemluvím o situaci, kdy ten certifikát není v souboru. Je celkem zábava vám vysvětlovat elementární věci, ale dlouho mi to asi nevydrží.

>Počkat, „asymetrickým šifrováním“ myslíte SSL? Nebo co si pod tím mám představit?
>Asymetrické šifrování běžně používá můj prohlížeč kdykoli přistupuji na nějakou stránku přes HTTPS.

Prohlížeč funguje tak, že pomocí asymetrického šifrování (veřejný/soukromý klíč) se ověří identity a otevře se SYMETRICKÝ šifrovaný kanál. Pokud chcete více, tak vám prohlížeč nestačí.

„Snadnému odposlechnutí jména+hesla.“

Pokud už mám právo nainstalovat keylogger, tj. mám na cílovém počítači admina/roota, nebude pro mě problém zkopírovat si i ten soubor s certifikátem, případně do krypto-tokenu (nabízí je KB vůbec?) poslat svoje data k podpisu.

„Případně zneužití šifrovacího klíče na straně banky.“

Nedokážu si představit, jak proti tomuhle jejich Java věc chrání - pokud se banka rozhodne škodit, pošle v té Java věci backdoor.

„To byla moje otázka na začátku - jak danou věc implementovat bez javy. Od vás, ani od jiného jsem se to zatím nedozvěděl.“

A já jsem vám odpověděl, že si myslím, že „daná věc“ nepřináší navíc žádnou bezpečnost, proto by bylo nejlepší neimplementovat ji vůbec.

„Prohlížeč funguje tak, že pomocí asymetrického šifrování (veřejný/soukromý klíč) se ověří identity a otevře se SYMETRICKÝ šifrovaný kanál.“

To je jasné, že se pomocí asymetrické kryptografie vyjedná symetrický klíč, který se pak používá. Ten applet to musí dělat stejně, jinak by to bylo strašně pomalé.

„Pokud chcete více, tak vám prohlížeč nestačí.“

Nevím, co více bych tady měl chtít.

"A tehdy neexistovalo HTML? :-O"

Ano, existovalo. Nějak se ten applet do prohlížeče dostat musel. Jak jeho existence souvisí s problémem? K internetovému bankovnictví je to velmi nevhodný nástroj. Neustále to posílá velké množství údajů a po každém kliknutí znovu načítá stránku.

"Prosím, popište mi nějaký útok, kterému má tohle zabránit."

Man in the middle. Nebo mám otázce rozumět tak, že dodnes používáte FTP a heslo si pro jistotu ukládáte v Total Commanderu?

"Nemyslím si, že by tam bylo něco, co by nešlo napsat v čistém HTML + JS roku 2001. V IE5 určitě chodily rozličné „interaktivní“ věci."

Ne, tehdy to nešlo. Podpora byla v každém prohlížeči jiná a v IE dost tristní. Výkon JS byl mizerný a knihoven pro něj bylo málo. Technicky by to asi nakonec vyřešit šlo, ale s náklady řádově vyššími.

"Ale i tak, proboha, je rok 2013."

Tak v tomto s vámi souhlasím. Ačkoliv jsem přesvědčen, že se v případě KB v ranném počátku jejich internet bankingu jednalo o výborné řešení, tak i přesto bych čekal, že alespoň jednou za pět let budou inovovat. Dnes, kdy SSL je standard, problémy kolem HTTPS podchyceny a když tu máme výkonný javascript a moře knihoven, dnes už k javovskému appletu není jediný důvod.

"Jak se v tomto případě liší uhádnutelné heslo od uhádnutelného certifikátu?"

Uhádnutelné heslo je "zuzanka12", zatímco certifikát je velký soubor plný čísel. Statisticky je větší šance uhodnout krátké heslo, než tisíc číslic.

"Počkat, „asymetrickým šifrováním“ myslíte SSL? Nebo co si pod tím mám představit?"

SSL je jedna z techologií toto umožňující. Její podpora v prohlížečích počátkem tisíciletí nebyla zrovna příkladná. Zcela chápu potřebu šifrovat si to ve vlastní režii.

"Asymetrické šifrování běžně používá můj prohlížeč kdykoli přistupuji na nějakou stránku přes HTTPS."

A to ještě dnes používáte IE5 v tak staré verzi? Nebo je to čistě tvrzení ve stylu "tehdy jsem taky nebyl majorom, ale terazky hej"? Jasně, dnešní prohlížeče už jsou co se HTTPS týká poměrně slušně vybavené.

Zkrátka, nedaří se vám vyvrátit tvrzení "v době spuštění byl KB velmi dobrým řešením tehdejších problémů". Že dnes už je to řešení zaostalé a přežité je věc jiná, na které se shodneme.

„K internetovému bankovnictví je to velmi nevhodný nástroj. Neustále to posílá velké množství údajů a po každém kliknutí znovu načítá stránku.“

Bohužel je to nevhodný nástroj pro většinu věcí i teď (třeba diskuze na Rootu), přesto bych nejásal, kdyby Root měl diskuze jako aplet.

„Man in the middle.“

Trochu přesněji, prosím… MITM řeší SSL/TLS, nad kterým běží HTTPS. Nemusí tam kvůli tomu být Java. A myslíte, že když se útočníkovi podaří podvrhnout stránku, nepodaří se mu podvrhnout vlastní applet?

„Uhádnutelné heslo je "zuzanka12", zatímco certifikát je velký soubor plný čísel.“

A teď si představte, že místo asymetrického certifikátu uživateli dáme soubor, jehož obsahem bude kvalitní heslo, a uživatel bude tento soubor nahrávat „do stránky“ úplně stejně, jako dnes certifikát.

„Její podpora v prohlížečích počátkem tisíciletí nebyla zrovna příkladná. Zcela chápu potřebu šifrovat si to ve vlastní režii.“

OK, chápu, pokud bylo důvodem exportní omezení na silnější šifry než 40bit RC4 nebo 40bit kripledes na konci minulého století, Java aplet se fakt mohl hodit. Ale - jak říkám - je rok 2013.

„Zkrátka, nedaří se vám vyvrátit tvrzení "v době spuštění byl KB velmi dobrým řešením tehdejších problémů".“

Dobře, souhlasím, že tehdy pro to byl důvod.

„Že dnes už je to řešení zaostalé a přežité je věc jiná, na které se shodneme.“

S vámi jo, ale s Pomocným kryptografem ne.

>SSL je základ a pokud by v něm byla díra umožňující pozměnit komunikaci, tak si
s Java appletem moc nepomůžete. Útočník vám podá jiný.

Pokud mi útočník dodá kompromitovaným SSL kanálem jiný applet, tak nebude sedět digitální podpis appletu na úrovni javy - to mohu poznat.
Jistě - poznat to nemusím. Ale to už mohu rovnou říct, že nemusím poznat ani podvržený SSL certifikát - spousta lidí nepozná ani jedno.

>Jinak nevím, co má Java společného s IE only.

To já taky nevím co, ale vím, že něco rozhodně ano :-D Snad všechny velké business java systémy, které jsem na počátku století vídal mělo jako tenkého klienta IE only webový front. Mohu jenom hádat, že byly nějaké komponenty, které umožňovaly levně a rychle vytvářet ActiveX prvky a dělat to do čistého html bylo příliš komplikované, ale taková byla prostě realita tehdejších let.

„Pokud mi útočník dodá kompromitovaným SSL kanálem jiný applet, tak nebude sedět digitální podpis appletu na úrovni javy - to mohu poznat.“

Aha, takže MITM na SSL nepoznáte, ale MITM na Javu jo. Já tedy buď nepoznám ani jedno (jsem BFU, co všechny hlášky o neplatném certifikátu odklikne - v browseru i v Javě) nebo to poznám hned, jak na tu stránku vlezu (varování browseru neodkliknu) a pak Java ani nepřijde ke slovu.

SSL netřeba pozměňovat. Stačilo tiše přepnout na nešifrovanou komunikaci. Uživatel nic nepoznal. Jo, že dneska už by to poznal a že prohlížeče kdejaké podezřelé chování kolem certifikátů a manipulací s adresním řádkem buď blokují nebo bonzují? Jo, dnes už jo.

Ale tomu asi Java moc nepomůže, protože uživateli přes to HTTP pošlu vlastní applet.