Kritická zranitelnost v Oracle Java umožňuje vzdálenou manipulaci s obsahem

Byla objevena zranitelnost CVE-2016-0636 v produktu Oracle Java, která umožňuje vzdálenému útočníkovi modifikovat prostředí prohlížeče a prohlížený obsah. Využití této zranitelnosti nevyžaduje dodatečnou autorizaci, ani autentizaci [CSIRT.CZ].

25.3.2016 09:55 | Ladislav Hagara | Bezpečnostní upozornění

Komentáře

[Petr Tomášek]

Džava? To ještě někdo používa, more?

[Lol Phirae]

V prohlížeči už moc ne, protože se podpora NPAPI pluginů začíná limitně blížit nule (v Chrome již nefunguje, FF taky odstraní co nevidět.)

[Bystroushaak]

Už je konečně na čase. Teď je ještě otázkou, kdy to konečně dojde i všem institucím, které javu úplně nesmyslně vyžadují. Naposledy jsem na to narazil při odevzdávání výkazu na OSSZ.

[Radek Miček]

Už je konečně na čase.

Proč myslíte? Nebude WebAssembly horší než JVM bajtkód?

[Bystroushaak]

Jestli bude lepší, nebo horší, než JVM bajtkód nejsem schopný říct, ale určitě bude lepší, než tenhle plesnivý ekosystém děravých, nenažraných pluginů.

[Radek Miček]

ale určitě bude lepší, než tenhle plesnivý ekosystém děravých, nenažraných pluginů

Prohlížeče ale také obsahují bezpečnostní chyby a hádám, že pokud bude přidána speciální podpora pro efektivní vykonávání WebAssembly, tak se prostor pro chyby zvětší.

[Filip Jirsák]

Mohl byste napsat, které instituce vyžadují Javu nesmyslně, pro co ji vyžadují a jak byste danou funkci nahradil? Alespoň některé případy.

[Bystroushaak]

Nemohl, seznam si nikde nevedu. Z hlavy dám tyhle dvě:

• Česká Správa Sociálního Zabezpečení
• Tendermarket

Oba dva vyžadují Javu na vyplnění (validaci hodnot) vcelku triviálních formulářů přes HTTPS, tedy z mého pohledu naprosto zbytečně. Asi bych dokázal pochopit, kdyby tyhle formuláře nějak pracovaly třeba s certifikátem, šifrováním přes smartcard, nebo tak něco, ale nic takového tam není. „Výhoda“ má být asi že je applet podepsaný, což ale stejně v praxi naprostá většina uživatelů nekontroluje a pokud by byla stránka a JavaScript přeneseny z certifikátem podepsaného serveru, tak jsem na tom stejně.

Nutnost pouštět nějaké plesnivé Java aplety z minulého tisíciletí bezpečnost nijak nezvyšuje, naopak celý počítač vystavuje riziku dalšího vektoru útoku z vnějšku.

To ani nepočítám nenažranost Javy, která mi v tom dokázala zasekat čtvrt roku starý „herní“ počítač s 16G paměti a i5 procesorem, jak kdybych na tom spustil výpočty vzniku vesmíru.

[Bystroushaak]

Tak koukám, že na ten formulář se nedá pořádně odkazovat. Alternativní link je toto:

• https://eportal.cssz.cz/web/portal/tiskopisy-osvc-2015

[Filip Jirsák]

V Tendermarketu je ten formulář asi někde za přihlášením.

U ČSSZ je to formulář 602XML – tam je úspěch aspoň ta Java, dříve to byla jen aplikace pro Windows. Ano, to by se bez problémů dalo řešit HTML formulářem, jenomže k tomu by nebylo potřeba Software602…

[Bystroushaak]

U Tendermarketu je tuším u přidání nabídky k zakázce.

[j]

To se pletes, ta socialka tu javu vyzaduje pouze v pripade, ze ten formular chces podepsat, jinak si to vystaci s povolenym js. Jinak by me zajimalo, jak bys to udelal bez ty javy. Dtto KB/CSOB ... ty maj taky pokud hodlas pouzivat firemni bankovnictvi a podepistova kartou ... javu.

[Bystroushaak]

Přílohy:

• Snímek obrazovky.png (171507 bytů)
• Snímek obrazovky-1.png (54367 bytů)

To se pletes, ta socialka tu javu vyzaduje pouze v pripade, ze ten formular chces podepsat, jinak si to vystaci s povolenym js.

Ne.

Prvně to po tobě chce javu a když to odklikneš, tak se to zavře.

[j]

Co nechapes na tom, ze ten formular funguje i bez javy? Teda aspon v kazdym pricetnym browseru? Hlaseni na socialku sem pomoci nej - a bez javy - delal.

Hlasi to tohle:

Tento formulář vyžaduje rozšířenou funkčnost. Je potřeba nainstalovat nebo zaktualizovat java runtime environment (JRE) a příslušný zásuvný modul (plug-in) do webového prohlížeče.

Pokud je plugin natvrdo off, pokud je na vyzadani, tak vyskoci zda povolit (zadny hlaseni), a i kdyz ho nepovolis (zcela tu hlasku ignorujes), tak to normalne funguje. Firefox i Palemoon.

[Bystroushaak]

Co nechápeš na tom, že mi to nefunguje? Ve firefoxu (palemoonu) se okno samo zavře, v chromiu to zobrazí tuhle dementní hlášku a to je všechno. O tom nehodlám dál diskutovat, teď jsem to znova zkoušel.

[aceman]

Akoze ta firma ti posle nejaky kod (ci uz JS alebo Java), ktory akoze nieco podpise a potom to odosle do tej firmy? To je naco dobre, ked doveryhodnost takehoto podpisu je nulova, z pohladu pouzivatela? Program mohol podpisat hocico, pouzivatel nema nad tym kontrolu. Zda sa, ze tieto firmy to maju principialne zle. Program ma dodat pouzivatel, taky, ktoremu veri a vie ze podpise len ten dokument, ktory mu da (pouzivatel).

Alebo ako je to riesene?

[Filip Jirsák]

Výhoda elektronického podpisu je v tom, že jeho bezpečnost nezávisí na tom, kdo algoritmus implementoval, a dá se kdykoli zpětně ověřit. Když počítáte hash nějakého dokumentu, musí vám vyjít pokaždé stejný, ať zvolíte jakoukoli implementaci. Pokud nějaká implementace vrátí jiný hash, je chybná. Podobně je to s šifrováním a podepisováním.

[aceman]

Spravne. Preto sa pytam, ako sa tu zabezpeci, ze je podpisany ten dokument, ktory si myslim, ze podpisujem, ked podpisovaci program je zo servera?

Pokial viem, elektronicky podpis je "produktom" sukromneho kluca a konkretneho dokumentu. V tomto pripade sa mi javi, ze sukromny kluc "da pouzivatel z ruky" neznamemu programu, ktory s nim neznamym sposobom nalozi a moze vytvorit dalsie elektronicke podpisy.

[Filip Jirsák]

Pokud uživatel dá soukromý klíč z ruky, bezpečné to samozřejmě není. Bezpečné implementace jsou třeba takové, kdy máte soukromý klíč uložený na čipové kartě nebo tokenu a nejde jej z toho zařízení jednoduše získat – a podpis vytváří přímo to zařízení. S takovými zařízeními ale dnes z prohlížeče nelze pracovat přímo, jedině přes nějaký plugin – nejlepší na to je v současné době právě Java. Ještě bezpečnější je taková implementace např. tokenu, který i ukáže, co podepisuje.

[aceman]

Nemal by potom taky plugin stacit jeden standardizovany (ked uz teda nie je priamo v prehliadaci), ktory by nebol pod vplyvom konkretnej banky? Cipova karta/token a plugin by mali byt z ineho zdroja ako z konkretnej firmy, aby to mohlo byt aspon trochu doveryhodne.

[Filip Jirsák]

Může být. Nebo to může být rovnou součástí prohlížečů. Jenže není. A jak už jsem psal, ono je to dost důvěryhodné i tehdy, když ten plugin je od té banky. I když ta čipová karta nebo token nezobrazí hash, který podepisují – uvědomte si, jak by ten útok vypadal. Banka vám zobrazí dokument, který údajně podepisujete, a ve skutečnosti vám k podpisu podstrčí jiný. Jenže po tom podpisu vám ten dokument i s podpisem obvykle ukáže. Takže by banka měla tři možnosti – rovnou vám ukázat ten podvržený dokument – to byste na ten podvod ale okamžitě přišel. Nebo vám ukázat ten původní dokument, ale bez podpisu – což by bylo podezřelé, proč vám neukážou ten podepsaný dokument. A nebo neukazovat nic – což je opět podezřelé, je přece logické, že vám ten podepsaný dokument ukážou. Takže ano, banka v takovém případě fixlovat může, ale provalí se to do jedné minuty od podpisu.

[aceman]

A ako normalny pouzivatel odhali, ci zobrazeny dokument je podpisany, alebo nie? Ako si "volnym okom" overi podpis? Myslim, ze pokial zobrazovanie riesi ten nedoveryhodny plugin z banky je "fixlovat" velmi trivialne. Nevidim ziadny dovod aby banka ukazala podvrhnuty dokument, ale na druhu stranu preco by nevedela zobrazit povodny dokument, ktory sa bude javit podpisany?

Zobrazovanie/kontrolu podpisu opat musi robit nejaky "doveryhodny" kod tretej (nezavislej) strany.

[Filip Jirsák]

Zobrazení samozřejmě nemůže řešit ten plugin. Nejsnazší je, když ten dokument je PDF – pak si ho uživatel může zobrazit ve vlastním prohlížeči PDF, uvidí tam i podpis a může ho snadno ověřit.

[aceman]

No a preto sa pytam ako to v tych bankach funguje. Mne sa totiz zda, ze zobrazovanie riesi len ten plugin. Cele podpisovanie a komunikacia zrejme prebieha v priehliadaci+plugine. Pochybujem, ze si pouzivatel moze dokument/pdf ulozit/pozriet vo vlastnom prehliadaci PDF. A aj keby mu plugin dovolil si ho vyexportovat, stale to nehovori nic o tom, ci si plugin nepodpisal dalsie dokumenty, ktore pouzivatelovi neukaze.

[Filip Jirsák]

Jak je to v bankách netuším, nikdy jsem neměl internetové bankovnictví založené na elektronickém podpisu, vždy to bylo na jednorázových heslech. Pokud ale vzniká PDF dokument, není žádný důvod, proč by uživatel neměl možnost si ho uložit. Spíš jde o to, jak starý je ten systém – protože u toho podání chcete mít i strukturovaná data, a vložení datového souboru do PDF je relativně nová možnost – v 10 let starém systému to nebude.

A aj keby mu plugin dovolil si ho vyexportovat, stale to nehovori nic o tom, ci si plugin nepodpisal dalsie dokumenty, ktore pouzivatelovi neukaze.

Bavíme se o bezpečném řešení, tedy nepodepisuje plugin, ale token nebo čipová karta. A uživateli by asi bylo nápadné, kdyby měl podepsat tři dokumenty místo jednoho.

[aceman]

Tak dakujem za odpovede, ale asi sa nikam nedostaneme. Ja som sa nepytal na teoreticky bezpecne riesenie, ak ho nikto nepouziva. Chcel som si overit, ako funguju tie riesenia, ktore v Jave ponukaju tie banky. Ano to potom mozeme porovnat s teoretickym riesenim. Ale najprv som sa pytal ako to riesia tie banky.

[vh]

az pujde z prohlizecu primo v javascriptu pouzivat elektronicky podpis, tak pozadavky na javu ubudou

[j]

Z javascriptu? Jen to probuh ne ... to uz bude asi tak 100x bezpecnejsi poslat do banky stoh podepsany prazdnych papiru a rict jim, at si tam vyplnej co potrebujou.

[Bystroushaak]

Pokud bych si měl vybrat mezi bezpečností Javy (pluginu, ne celé platformy), kterou spravuje Oracle (přezdívaný taky jako Velký korporátní satan) a bezpečností JavaScriptu, který spravuje google, mozilla a pár dalších, tak beru JavaScript, i když to jako jazyk stojí za hovno.

[Filip Jirsák]

Výhoda elektronického podpisu je v tom, že se dá implementovat bezpečně bez ohledu na to, co má uživatel nainstalované na počítači. Takže tam můžete mít sto zlých JavaScriptů, a stejně tím nepodepíšete nic, co by uživatel nechtěl podepsat.

[aceman]

Napriklad ako sa to da implementovat?

[ujo imro]

Napr. cipovou kartou, ktora musi byt pritomna pri podpise a uklada privatny kluc (bez moznosti exportu)?

[R]

A ako osetris, aby pouzivatel tu kartu vytahoval? Alebo aby sa podpisal len jeden dokument a nie 3 za sebou?

[Filip Jirsák]

Ovladač té karty se před každým podpisem minimálně dotáže, zda se má privátní klíč použít, případně se pokaždé zeptá na PIN.

[aceman]

Lenze to stale nehovori nic o tom, co sa ide podpisovat. Asi maloktora citacka dokaze nejako nezavisle sama zobrazit subor (ci hash), ktory sa ide podpisat. Preto by mal byt este nejaky medzikrok (program), ktory toto zabezpeci a ktory nie je od tej banky.

[Filip Jirsák]

Jak už jsem psal, banka by neutajila moc dlouho, že si nechala podepsat jiný dokument, než který vám zobrazila. Zobrazení hashe na tokenu je lepší řešení, ale je výjimečné. Teoreticky by v tomhle mohly pomoci chytré telefony, pokud by podepisování bylo integrované přímo v systému (tak, aby nebylo napadnutelné z uživatelského prostoru).

[aceman]

Doteraz som nepochopil dokaz, preco by to banka neutajila. Pri existujucich rieseniach. Nie tych teoreticky spravnych.

[Filip Jirsák]

Existující nejbezpečnější řešení jsou taková, že příkazy bance potvrzujete jednorázovým kódem, který je odvozený od platebních údajů. To vás chrání před útokem třetí strany, ale ne před útokem z banky. Podobně jsou na tom neelektronické příkazy „chráněné“ podpisem nebo kontrolou občanky. Pokud nějaká banka používá elektronický podpis, nevím, jak ta implementace konkrétně vypadá. Každopádně zrovna vztah klienta k bance vyžaduje značnou důvěru i bez jakéhokoli elektronického bankovnictví, takže si nedovedu představit, že bych bance nevěřil, že nebude falšovat dokumenty, ale zároveň bych jí svěřil peníze.

[aceman]

Banka bola len priklad, ale hovorilo sa tu o vselijakych inych uradoch, kde ich doveryhodnost je tiez otazna. Ale aj v pripade banky, je rozdiel, ci Vam banka peniaze ukradne len tak, alebo Vam ich ukradne a bude to dokladovat falosnym dokumentom s Vasim realnym elektronickym podpisom. V prvom pripade mozno mate nejaku sancu. Neviem ci v sucasnom prostredi je mozne nemat banku, alebo si najst banku, ktorej mozete vo vsetkom doverovat. Tak preco nebyt opatrny aspon tam kde sa da.

[Bystroushaak]

A ako osetris, aby pouzivatel tu kartu vytahoval? Alebo aby sa podpisal len jeden dokument a nie 3 za sebou?

Lepší zařízení, jako třeba Yubikey (mohl bych už sakra dopsat tu recenzi) mají kapacitní snímač, který musíš stisknout pokaždé, když chceš něco podepsat.

[aceman]

A na nom vidim co podpisujem?

[Bystroushaak]

Nevidíš, ale zabráníš tím tomu, aby zařízení podepisovalo bez tvého vědomí. Je to jen o krok lepší a ne úplné řešení. Nějaký čas jsem nad tím přemýšlel a jediné, co mě napadá je mít v hlavě neurální implantát a podepsat to přes něj, protože jinak nikdy skutečně nevíš, co se to vlastně v počítači děje.

[Filip Jirsák]

Vždy podepisujete hash. Takže pokud chcete implementovat až takhle bezpečný podpis, musíte nejprve vyřešit, jak bezpečně získat hash toho podepisovaného dokumentu.

[pavele]

Nevím o tom, že bych musel na Yubikey stiskat tlačítko při podepisování, zobrazí se mi: "Zadejte pin". Jedině že by jsi ten pin zadával stisknutím toho tlačítka, což by ovšem nebylo moc bezpečné...

[Bystroushaak]

To záleží jak ho nastavíš. Já jsem si nastavil oboje, tedy jak stisknutí tlačítka, tak PIN (s tím že PIN se pamatuje asi 5 minut). V opačném případě by stačilo malware odposlechnout PIN a celá idea hardwarového tokenu, který útočník nemůže zneužít by byla krapet zbytečná.

[pupala]

Moje gemalto si pýta sec-auth-pin vždy nanovo pri každom podpise. Dokonca aj primary-auth-pin, ale tam je tuším možnosť nastavenia časového okna platnosti.

[pavele]

To používáš externí hardwarový token s klávesnicí? Pin přece není problém odposlechnout během zadávání na PC klávesnici.