Java SE 7u25 a bezpečnostní chyba v Javadoc

Oracle vydal Javu SE 7u25. Opraveno je 40 bezpečnostních chyb, z nichž 37 je zneužitelných vzdáleně. Bezpečnostní chyba byla nalezena i v nástroji pro generování dokumentace Javadoc (VU#225657, frame injection). Je-li dokumentace přístupná pomocí webového serveru, měla by být opětovně vygenerována pomocí opravené verze Javadoc.

19.6.2013 11:42 | Ladislav Hagara | Bezpečnostní upozornění

Komentáře

[jehovista]

To zas bude v diskuzich nablito.

[Bedňa]

Neviem prečo? Java je predsa šmejďárna :)

[bbbb]

ano, utekaj si k svojmu jedinemu dokonalemu pure C99999

[mankind_boost]

Asi se všichni shodneme na tom, že Java (přinejmenším její implementace od Oracle) je naprostá žumpa.

[Franta]

-1

[mankind_boost]

Na každém šprochu pravdy trochu.

[Miriam]

Bůůů, bůůůůů, kritika, rychle zacpat uši polštářem a schovat se do skříně

[ewew]

Už by mohli dať bezpečnosť javy do poriadku. Vypnúť javu nie je riešenie, pretože veĺa stránok ani nefunguje bez povolenej javy.

[Bedňa]

Nainštaluj si doplnok na vypínanie Javy a zapínaj len tam, kde si myslíš že by to mohlo byť bezpečné.

[8an]

Dneska naštěstí už jenom pár specialit... I bankovnictví Komerční banky se konečně postupně Javy zbavuje.

[bbbb]

a dava tam co? :D python s djangom?

[Andrej]

flash anyone? https://moja.tatrabanka.sk/

[j]

Takovy stranky jsou ovsem zcela nezajimavy. Rad vyhovim provozovateli - nema zajem o me (a potencielne me penize) => ja nemam zajem o nej.

[kolbert]

Reci o potencialnim placeni sluzeb/software me u Cechu vzdycky pobavi :)

[bluemoon]

Nejhorsi je to, ze java je na temer vsech informacnich a zakazkovych systemech, kde potrebujete elektronicky podepisovat zadosti a dokumenty.

Nedavno jsem s technickou podporou resil problem pristupu kvuli tomu, ze nas zakaznik pouzil token, ze ktereho nelze klic dostat a zakazkovy system po nem chtel pfx soubor jak s certifikatem tak klicem. Bylo mi z toho docela smutno, ze java obstarava pristup k ulozisti klicu.

[Filip Jirsák]

Vzhledem k tomu, že to je prakticky jediný způsob, není se co divit. Alternativou je snad jen ActiveX pouze pro Internet Explorer, případně napsat a distribuovat vlastní plugin po vzoru Javy nebo Flashe.

[Franta]

Alternativou resp. správným řešením je vysrat se na „webové aplikace“ a udělat normální desktopovou aplikaci, ať už v Javě nebo třeba C++. Když už to má být web, tak se držet standardního API.

[Filip Jirsák]

Ne pokud je to určeno pro širokou veřejnost. Já si nebudu instalovat speciální aplikace banky, pojišťovny, finančního úřadu, pošty a bůhvíkoho ještě jenom proto, abych jim jednou za rok něco elektronicky poslal…

Standardní API na webu je dost mlhavý pojem – jinak dnes se tomu standardnímu API říká HTML5. Každopádně bych podporu pro elektronický podpis ve „standardním webovém API“ uvítal mnohem víc, než spoustu z mého pohledu spoustu zbytečností, které se do HTML5 dostávají.

[Franta]

Já si nebudu instalovat speciální aplikace banky, pojišťovny, finančního úřadu, pošty a bůhvíkoho ještě jenom proto, abych jim jednou za rok něco elektronicky poslal…

Ona by stačila jednoduchá GUI aplikace pod svobodnou licencí pro vyplňování a podepisování formulářů. Výstupem by byl buď podepsaný soubor (ten by uživatel sám odeslal e-mailem nebo třeba přes web) nebo by ho ta aplikace rovnou odeslala na nějakou webovou službu. Vstupem by byla definice formuláře + volitelně adresa webové služby. Stejná aplikace by šla použít pro víc institucí.

Alternativou je akceptovat data podepsaná GPG nebo OpenSSL a dodat jen nějaký skript, který podpis usnadní.

Každopádně bych podporu pro elektronický podpis ve „standardním webovém API“ uvítal mnohem víc, než spoustu z mého pohledu spoustu zbytečností, které se do HTML5 dostávají.

Souhlas, tohle by se hodilo. Jen je otázka, jak zajistit, aby uživatel podepsal skutečně to, co si myslí, že podepisuje – aby mu web nepodstrčil k podepsání jiná data, než se zobrazjí ve formuláři. Např. by tam bylo pomocí CSS skryté políčko „chci od vás dostávat spam e-mailem“ nebo „zavazuji se odebírat vaše služby příštích deset let“.

[Filip Jirsák]

Ta aplikace už existuje – říká se jí webový prohlížeč. Akorát ten e-podpis sama o sobě neumí…

[Franta]

Ona neumí mnohem víc věcí (jako třeba bezpečně ukázat uživateli, co přesně podepisuje) a naopak umí spoustu zbytečností (z tohoto pohledu), rozhodně to není „jednoduchá GUI aplikace“.

[Filip Jirsák]

Uživatel by neměl podepisovat XML, ale např. PDF vyrobené z toho XML (zároveň to XML je uvnitř vložené). To webové prohlížeče umí. Další obrovskou výhodou je, že webový prohlížeč má každý uživatel už nainstalovaný. A ta jednoduchá GUI aplikace by zase až tak jednoduchá nebyla. Pro praktickou editaci formulářů potřebujete formulář zobrazit v určité podobě (takže vykreslovací jádro), potřebujete tam mít nějakou kontrolu a doplňování (takže nějaký skriptovací jazyk), potřebujete napojení na externí číselníky (takže podpora HTTP komunikace). No a o moc víc už toho webový prohlížeč neumí – možná přehrávání multimédií. Ale nemá smysl psát zcela nový internetový prohlížeč, který akorát nebude umět přehrávat video.

[petr_p]

Řešením je rozdělit podepisování a aplikaci (webovou nebo jakoukoliv jinou). Tedy aplikace dá uživateli data jako soubor, uživatel si je podepíše ve svém důvěryhodném nástroji a podpis nebo podepsáná data uživatel opět dodá aplikaci.

Jaký na to bude API (jestli soubor, socket, nebo volání funkcí), je už celkem jedno.

Nebude to sice tak jednoduché jako stisk jednoho tlačítka, ale aspoň se začnou uživatelé dožadovat, aby se podepisovaly otevřené a snadno čitelné dokumenty. To vůbec není případ obecného (třeba s vestavěným SWF objektem) PDF nebo jakýsi stovky kilobajtů dlouhý ad-hoc XML dokument (jako dnes vypadá daňové přiznání) nebo nějaký blob (jako dělají banky).

[Filip Jirsák]

Myslím, že třeba ve webmailu je to jednoduché – buď to bude na jedno tlačítko přímo na webu, nebo uživatelé e-maily podepisovat nebudou. Souhlasím, že webmail a většina web* aplikací je nesmysl a bylo by možné napsat lepší a uživatelsky přívětivější desktopové aplikace. Jenže ty webové aplikace tady jsou, jejich desktopové ekvivalenty jsou ještě horší než ty webové, takže asi nezbývá, než se snažit aspoň ty webové aplikace nějak zkulturnit. Ostatně už se takhle do prohlížečů přidala podpora pro vícenásobný upload, pro drag-and-drop, pro přehrávání videa – takže elektronický podpis by byl jen další v řadě. Ostatně i v tom prohlížeči to může být konfigurovatelné a kdo bude chtít, může soubor předat své důvěryhodné aplikaci.

[Franta]

buď to bude na jedno tlačítko přímo na webu, nebo uživatelé e-maily podepisovat nebudou

V tom případě je lepší, když podepisovat nebudou – vytvářelo by to pouze falešný pocit bezpečí a více zmatků. To bude lepší, když e-mail podepíše na serveru poskytovatel pomocí DKIM a na straně příjemce se to ověří.

Protože ve skutečnosti by to byl poskytovatel, kdo by měl nad podepisováním moc – nikoli uživatel. Ten by pouze stiskl to jedno tlačítko a JavaScript (právě stažený ze serveru poskytovatele) by cosi poslal na podepisovací API prohlížeče a nechal to podepsat uživatelem. Ale kdo zaručí, že to „cosi“ bylo totéž, co psal uživatel do HTML formuláře?

Oproti tomu podepisování na serveru je celkem rozumné řešení – většinou ti totiž stačí vědět, že e-mail pochází od nějaké organizace (domény) a nemusíš mít ověřenou identitu konkrétního odesílatele (osoby). Výhodou je, že koncový uživatel nemusí dělat vůbec nic, resp. dělá věci stejně jako dřív a je to bezpečnější. Pokud potřebuješ „end-to-end“ bezpečnost mezi konkrétními osobami, tak to vyžaduje trošku víc úsilí, znalostí a technického vybavení.

[David Jaša]

To bude lepší, když e-mail podepíše na serveru poskytovatel pomocí DKIM a na straně příjemce se to ověří.

Leda v případě, že se c2s smtp nahradí něčím jiným, co bude schopno zaručit pravost odesilatelovy emailové adresy.

[Franta]

V SMTP se klient ověří jménem a heslem – to určuje jeho e-mailovou adresu (společně s doménou serveru) nebo ho to alespoň spolehlivě identifikuje.

Když jako server dovolíš posílat z jiných domén, tak tato adresa už ověřená nebude, ale bude ověřené, že to poslal někdo z tvých uživatelů a ví se, kdo to byl. Na straně příjemce se pak zobrazí něco jako:

Odesílatel: franta@example.com (neověřeno)
Odesláno přes: example.net (ověřeno)

A víš, na čem jsi.

[Filip Jirsák]

Já jsem si pod webmailem představoval GMail nebo Seznam e-mail. Ve firmách je asi přeci jen rozšířenější Outlook. Já bych přes GMail klidně v prohlížeči podepsaný e-mail poslal – nemám důvod Googlu věřit méně než třeba Microsoftu, AMD, Suse nebo Intelu. A šifrovat podpis s tužkou na papíře opravdu nebudu.

[Franta]

Takové šifrování/podepisování ale ztrácí smysl resp. posouvá se na úplně jinou úroveň – vypovídací hodnota takového podpisu (resp. šifry) je: nějaký uživatel, za jehož identitu ručí poskytovatel XYZ, poslal přes tohoto poskytovatele e-mail (resp. zašifrovaný e-mail si přečte osoba pověřená poskytovatelem XYZ).

Nic víc ti to neřekne. A pro tento účel bohatě stačí DKIM a TLS spojení mezi servery. Nedává smysl se trápit s nějakou atrapou dalšího šifrování/podepisování.

Pokud to má být „end-to-end“ bezpečnost mezi dvěma uživateli, je potřeba použít software, který je pod nezávislou kontrolou a který nikam neodesílá soukromé klíče.

P.S. já bych tedy Googlu ani Microsoftu jakožto americkým firmám nevěřil. Daleko víc budu věřit svobodnému softwaru, který si může proklepnout kdokoli od chlápků z NSA přes ruské a čínské hackery až po české programátory.

[stativ]

Pokud je to v JavaScriptu, tak to běží lokálně na počítači uživatele, a tudíž v tomhle smyslu není žádný rozdíl mezi nějakou speciální aplikací a JS v prohlížeči.

[xkucf03]

Třeba se jednou dopracujeme k tomu, že to tak¹ bude, ale zatím je mezi nimi značný rozdíl. JS se stahuje pokaždé znova² a server mu může podstrčit, co chce a i to průběžně měnit³. Desktopovou aplikaci si jednou stáhneš, jednou si zkontroluješ elektronické podpisy, hashe, pročteš si její zdrojáky nebo si necháš udělat audit (dle svého uvážení) a pak ji používáš a aplikace funguje pořád stejně. V případě aktualizace si uděláš diff zdrojáků, nový audit nebo věříš autorům aplikace, každopádně to máš pod kontrolou a věci se dějí podle tvého.

_{[1] což vyžaduje určitou infrastrukturu, ne až tak složitou, ale zatím to prostě chybí
[2] případně se bere z mezipaměti, ale to uživatel neovlivní – naopak server si dle svého uvážení může vynutit tichou aktualizaci aplikace – uživatel nic nepozná
[3] webová aplikace, která jednou fungovala dobře a spolehlivě může najednou začít uživateli škodit, aniž by uživatel něco udělal (např. nainstaloval novou verzi)}

[Václav HFechs Švirga]

Tohle by mohlo fungovat ne?

[Václav HFechs Švirga]

V každém případě dokud takové API (nevím o tom že by vznikalo, nebo má někdo nějaké info?) nebude a prohlížeče ho nebudou podporovat, tak se nepohneme. A rozhodně se musí to api navrhnout velmi kvalitně, aby nenastal problém s bezpečností. Zde ale architektům html technologií celkem věřím, protože jsou hodně paranoidní. Jako příklad dám třeba možnost javascriptu udělat fullscreen. Ve flashi naprosto normální věc (nemožnost dát si přes celou obrazovku video na youtube by asi každého nasr...), ale přes js (html5 video) to otravuje potvrzením, protože by někdo právě mohl vykreslit něco podvrženého (třeba ve fullscreenu celý nový prohlížeč, doufat že se trefil do verze a vzhledu OS a doufat, že tam netušící uživatel zadá přihlašovací údaje do e-bankovnictví - ve flashi no problem, ale stejně to nikdy nikdo neudělal ).

[xkucf03]

P.S. já bych tedy Googlu ani Microsoftu jakožto americkým firmám nevěřil.

Tohle je celkem jednoduchý a funkční obchodní model:

Vláda poskytuje:

• peníze daňových poplatníků (výnosné státní zakázky)
• boj proti „pirátství“
• poškozování konkurence
• průmyslovou špionáž v zahraničí

Firma vyvíjející uzavřený software poskytuje

• informace o zneužitelných bezpečnostních chybách
• backdoory na přání
• data domácích uživatelů
• data zahraničních uživatelů (vhodné mj. pro průmyslovou špionáž)

[Filip Jirsák]

V EU nikoho nezajímá, že jsem poslal e-mail přes GMail. Když ale ten e-mail bude podepsaný mým kvalifikovaným certifikátem, má v rámci EU právní platnost jako vlastnoručně podepsaný.

Do toho svobodného prohlížeče si přece klidně můžete implementovat funkci, která zkontroluje, že JavaScript poslaný serverem odpovídá zkontrolovanému vzoru.

Ten svobodný software nespouštíte na procesorech vyrobených americkými firmami?

[xkucf03]

V EU nikoho nezajímá, že jsem poslal e-mail přes GMail. Když ale ten e-mail bude podepsaný mým kvalifikovaným certifikátem, má v rámci EU právní platnost jako vlastnoručně podepsaný.

Pokud ale ten soukromý klíč svěříš Googlu[nebo jinému „cloudovému“ poskytovateli – a to takovým způsobem, že si ho klidně může poslat na svůj server, aniž by sis toho všiml], tak to ztrácí smysl a vypovídací hodnota takového podpisu je stejná, jako hodnota DKIM podpisu.

[Filip Jirsák]

Místo toho ho můžu poskytnout svému poskytovateli desktopového poštovního klienta nebo šifrovacího programu. Stejně tak ho poskytnu výrobci operačního systému, systémových knihoven, základní desky, procesoru a dalšího hardware... Těm všem také nevěříš a všechno si kontroluješ? Nebo máš někde hranici, a spoustě subjektů věříš -- výrobci hardware, správci tvé distribuce, vývojáři tebou používaného opensource softwaru? Tak já mám prostě tu hranici o kousek vedle a mezi ty důvěryhodné subjekty bych v tomto případě zařadil i GMail.

Vypovídací hodnota není stejná, e-mail podepsaný kvalifikovaným certifikátem má v EU právní váhu. To, jak jsem ten podpis vytvořil, nikoho nezajímá (pokud nedojde ke sporům), to, že svěřím privátní klíč GMailu je moje riziko. Já to tedy zatím dělám tak, že e-mail podepíšu svou utilitou (která ale používá implementaci podepisování od Oracle resp. původně Sunu) a pak podepsaný e-mail vložím do fronty na svém SMTP serveru. Ale mít možnost poslat to přímo přes GMail, udělal bych to -- a necítil bych se méně bezpečný, než dnes, zato by to bylo mnohem pohodlnější.

[Filip Jirsák]

Navíc tady byla celou dobu řeč o podepisování v prohlížeči, takže bych privátní klíč neposkytoval Googlu jako poskytovateli GMailu, ale Googlu jako autorovi Chrome

[xkucf03]

Ty opravdu nevidíš rozdíl mezi tím když:

• Google¹ ti² v jediné HTTP odpovědi pošle pozměněný JS, který ukradne tvoje klíče, a dál posílá zase standardní JS.
• Autor softwaru jednou za čas zveřejní novou verzi programu včetně zdrojových kódů, poskytne všem tu stejnou verzi, projde to přes distribuce, kdokoli ten kód může zkontrolovat a staré verze se archivují (obvykle s digitálním podpisem autora) a lze zpětně dohledat, co se kdy změnilo (+ k tomu máme i veřejně přístupné úložiště verzovacího systému).

?

_{[1] nebo nějaký MITM s přístupem k jeho důvěryhodným certifikátům
[2] selektivně jenom tobě – nikdo jiný se o tom dnes nedozví a nejde to zpětně dohledat}

[Filip Jirsák]

Implementace podepisování v prohlížeči by opravdu nemohla být udělána tak hloupě, aby se JS dostal k privátnímu klíči -- to by pak byla na nic.

Proti zaslání pozměněného JS se přeci lze bránit doplňkem v prohlížeči, který bude kontrolovat, že se JS nezměnil. Stejně jako jiné doplňky kontrolují, že se nezměnil HTTPS certifikát.

Z mého pohledu v tom rozdíl není. Buď Googlu věřím, že ten privátní klíč neukradne -- ne proto, že by se na to mohlo přijít, ale že to prostě neudělá. Pak mezi těmi dvěma případy není rozdíl. Nebo mu to nevěřím a beru to tak, že jediný důvod, proč klíče neukradne, je ten, že by se na to mohlo přijít. To je asi tvůj případ -- ale já služby takového poskytovatele nebudu používat vůbec. Navíc autor tvé distribuce taky může selektivně jenom tobě poslat podvržený balíček s webovým prohlížečem, který ukradne privátní klíč a vzápětí se nahradí standardním balíčkem.

A ještě jedna drobnost: "kdokoli může kód zkontrolovat" je z hlediska bezpečnosti nulový přínos. Bezpečnost zvyšuje pouze to, když někdo kód zkontroluje. Těch případů, kdy se spoléhalo na to, že někdo něco může udělat, ale pak se ukázalo, že to nefunguje, protože to ve skutečnosti nikdo nedělá, jsou miliony (ne jen v oblasti softwaru, ale třeba v ekonomice nebo v politice).

[xkucf03]

Navíc autor tvé distribuce taky může selektivně jenom tobě poslat podvržený balíček s webovým prohlížečem, který ukradne privátní klíč a vzápětí se nahradí standardním balíčkem.

To není zdaleka tak jednoduché: neví, ze kterého zrcadla stahuji, jestli nepoužívám nějakou proxy resp. jakou mám IP adresu (nemluvě o tom, že za jednou IP může být X dalších uživatelů nebo celé sítě), nikam nepíšu jméno a heslo. Naopak u webové aplikace je ta identita uživatele jasně svázaná s HTTP relací (cookie). Co se týče zpětné dohledatelnosti, je to taky úplně jinde: po podvrženém balíčku zůstanou soubory + digitální podpis, po podvržené HTTPS komunikaci nezbude nic (pokud ji explicitně nezachytáváš a nearchivuješ).

[Filip Jirsák]

Jediný rozdíl je v tom, že e-mail zná tvou identitu skrze přihlašovací údaje, zatímco distribuční místo balíčků tvou identitu možná nezná. Co se týče zpětné dohledatelnosti, psal jsem už v minulém komentáři, že podvržený balíček po sobě může zahladit stopy po té, co vykoná svou práci. Na rozdíl od JavaScriptu totiž má v systému rootovská práva, takže po něm žádné soubory zbýt nemusí.

To, že se třeba na OpenSSL dělá bezpečnostní audit zdrojáků, je sice fajn, ale v tom OpenSSL se může k privátnímu klíči dostat taky glibc nebo jádro, a ty už tak důkladným bezpečnostním auditem neprocházejí. Navíc je to pořád kontrola zdroje, ale nemáte zaručeno, že k vám na počítač se dostane OpenSSL z toho zkontrolovaného zdroje.

[petr_p]

Na každý váš případ spiknutí lze nalézt protiopatření. Pokud jste tak paranoidní, tak si binutils, gcc, glibc, linux a openssl můžete stáhnout a zkompilovat sám. Ostatně řada distribucí takhle funguje. A pokud jde o binární distribuce, tak si myslíte, že třeba Red Hat vyhodí milióny za certifikaci, a pak bude distribuovat poškozenou binárku?

[Filip Jirsák]

Na každý váš případ spiknutí lze nalézt protiopatření.

Stejně jako pro ten podpis e-mailu v prohlížeči.

[Jendа]

Pokud jste tak paranoidní, tak si binutils, gcc, glibc, linux a openssl můžete stáhnout a zkompilovat sám.

Jak ověřím pravost zdrojáků, které stahuji?

Ne, srsly, můj ISP automaticky analyzuje stahované tarbally a když je v něm Makefile, tak do něj přidá exec jeho backdooru. Co s tím můžu dělat?

A pokud jde o binární distribuce, tak si myslíte, že třeba Red Hat vyhodí milióny za certifikaci, a pak bude distribuovat poškozenou binárku?

Ano, myslím. A nemusí to být RedHat, může to být kterýkoli z jeho zaměstnanců, který má nad podepisováním kontrolu, může to být kterákoli vláda, která má nad RH moc, a může to být kterýkoli hacker, který naboural kteréhokoli z těchto zaměstnanců nebo vlád.

Vy si vážně myslíte, že když DigiNotar vyhodí milióny za certifikaci, tak pak bude prodávat MITM certifikáty?

[petr_p]

Ne, srsly, můj ISP automaticky analyzuje stahované tarbally a když je v něm Makefile, tak do něj přidá exec jeho backdooru. Co s tím můžu dělat?

Chytří pánové vymysleli hashovací funkce a asymetrickou kryptografii. Mně třeba FTP GNU ukazuje takové soubory s příponou sig. Mně třeba rsyncová zrcadla Gentoo ukazují soubory Manifest. Mně třeba stejné soubory nabízí look-a-side cache Fedory nebo podepsané zdrojové balíčky Red Hat Enterprise Linuxu nebo GNU/Debianu. A dokonce ty soubory vypadají stejně z různých sítí a přes různé protokoly.

Řekl bych, že možnostem, jak si ověřit původnost zdrojáků toolchainu, může kdejaký notář či tak zvaně důvěryhodná instituce závidět.

Ano, myslím. A nemusí to být RedHat, může to být kterýkoli z jeho zaměstnanců, který má nad podepisováním kontrolu,

Zrovna z pozice podepisujícího zaměstnance to tak snadné není. Zdrojáky musí někdo nacpat do verzovacího systému, zdrojáky musí nějaký systém zkompilovat, někdo musí balíček otestovat, někdo jej musí podepsat, po podpisu jej musí vrátit do systému, a tak dále. A různé kroky dělají různí lidé. Ti lidé často ani nemají přímý přístup k daným systémům, pouze s nimi komunikují. A všude se táhnou kontrolní součty, logy a zálohy. Z tohoto pohledu útočit na konci řetězce je čiré bláznovství. To už je rozumnější nechat se zaměstnat jako vývojář, který stojí na úplném začátku, protože ten už v podstatě vaří z vody. I když ani ten to nemá bez rizika, protože toho křížově kontroluje jiný vývojář a vedle toho ještě bezpečností tým se baví pročítáním kódu a různé systémy v různých fázích dělají rozdílové testy.

může to být kterákoli vláda, která má nad RH moc,

Myslíte vlády, které brečí, jak jim firmy utíkají s daněmi za hranice? Myslíte nad firmou, která sice má vedení v Severní Karolíně, ale v podstatě veškerý provoz je rozprostřen po celé planetě?

a může to být kterýkoli hacker, který naboural kteréhokoli z těchto zaměstnanců nebo vlád.

Jistě, že jednorázový incident se může přihodit. Proto ale máme logy a zálohy, abychom mohli rozsah útoku odhalit, oběti varovat a učinit protiopatření.

Vy si vážně myslíte, že když DigiNotar vyhodí milióny za certifikaci, tak pak bude prodávat MITM certifikáty?

Však taky skončil. Jenom to ukazuje, že nelze bezmezně věřit jedné straně, ale je třeba křížově kontrolovat. Přesně tak, jako lze ověřit zdrojáky toolchainu.

[Filip Jirsák]

Ad hashovací funkce a balíčky -- když se tohle všechno dá použít na stažení zdrojáků v C++ nebo zkompilované binárky Thunderbirdu, proč by úplně ten samý mechanismus nešlo použít pro stažení JavaScriptu GMailu?

Ad podepisování distribučních balíčků -- nezapomněl jste napsat, že nepopisujete Linux, ale Hurd 1.0? Se správou distribučního balíčku osobní zkušenost nemám, ale všude jsem vždy četl, že balíček má v distribuci správce jednoho nebo žádného, jen o velké projekty typu KDE se stará tým lidí. Z pozice vývojáře opensource a správce opensource projektu zkušenost mám, a křížové kontroly jiným vývojářem, bezpečnostní tým a různé systémy, které dělají v různých fázích rozdílové testy -- možná v nějakém paralelním hodně vzdáleném vesmíru. Tohle platí možná pro OpenSSL, neplatí to ani pro jádro nebo glibc.

[jas]

Popisovany proces sa zrejme netykal upstreamu, ale RHELu.

[petr_p]

proč by úplně ten samý mechanismus nešlo použít pro stažení JavaScriptu GMailu?

Velmi omezeně. Kód Gmailu distribuuje jenom Gmail. Nikdo jej nearchivuje, nepodepisuje, ani neredistribuuje. Navíc samotný Gmail vám nedistribuuje zdroják, ale až výsledek překladu. Minimálně je prohraný všelijakými kompresory a zatemňovači. Taky se kód liší pro různé uživatele nebo země. A taky pro různé user agenty. Nehledě na to, že se mění jako ponožky (prohlédněte si třeba druhou stránku výsledků vyhledávače Googlu – samotná data se dodávají jako javascript – v HTML nejsou).

Ad podepisování distribučních balíčků -- nezapomněl jste napsat, že nepopisujete Linux, ale Hurd 1.0?

Popisoval jsem změnu kódu v komerční distribuci. Konkrétně v RHEL, když si ho předchozí komentář vzal na mušku.

Se správou distribučního balíčku osobní zkušenost nemám

Já ano.

balíček má v distribuci správce jednoho nebo žádného

V nadšeneckých distribucích tomu tak bohužel je. Očividně je mezi linuxáky málo lidí ochotných něco dělat. To je asi důvod, proč existují distribuce jako CentOS nebo Scientific Linux nebo nakonec Ubuntu.

Tohle platí možná pro OpenSSL, neplatí to ani pro jádro nebo glibc

Přijďte se podívat příští jaro na den otevřených dveří do brněnského Red Hatu. Návštěvníci přicházejí s mylnou představou, že je to jeden hacker vedle druhého, co se hrabe v jádře.

[Franta]

Už to psal Petr, je to trochu shrnu:

• Obfuskovaný JS nelze považovat za zdrojový kód.
• Ve webových aplikacích splývají data a spustitelný kód – data se neustále mění, nemůžeš je pořád znova a znova kontrolovat, aplikace by byla nepoužitelná. Spustitelný kód by to kontrolovat chtělo, ale nikdy nevíš, zda ti ho web nepodstrčí uvnitř měnících se dat.
• I ten spustitelný kód se mění na webu příliš často, aby ho šlo efektivně kontrolovat (a nezabilo to použitelnost aplikace), mnohdy se i liší pro prohlížeče, uživatele, státy… Stačí se podívat jak často Google a jiné podobné firmy mění SSL certifikáty – kvůli tomu je jejich kontrola dost problematická, na uživatele neustále vyskakují nějaká varovná okna, až nakonec kontroly vypne… s JavaScriptem by to bylo podobné, ale ještě o dost horší.

[petr_p]

Distribuce distribuce už ti byla vysvětlena. Já dodám, že na citlivé programy, zrovna kryptografické knihovny, se běžně dělají certifikace, které zahrnují čtení zdrojáků.

[David Jaša]

Ne, správným řešením je slušná integrace klientského PKI do prohlížečů (a evoluce TPM do něčeho, co může fungovat jako trvale zastrčená smartkarta).

[Franta]

A jak bys třeba podepsal takovou banalitu, jako komentář na tomto webu? A jak bys ho před podepsáním zobrazil uživateli, aby si mohl zkontrolovat, že podepisuje skutečně to, co podepsat chce?

[David Jaša]

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Relativně rychle implementovatelná možnost (změny jen v prohlížeči): součástí JS API prohlížeče by byla funkce, které by se předala data (xhtml + css: pro opakovatelnou prezentaci a zároveň rozšiřitelnost) k podepsání. Prohlížeč by data znovu zobrazil, dal na výběr klíč, po odsouhlasení uživatelem podepsal a vrátil zpět.

Systémovější možnost: v systému by běžel démon se speciálními právy, který by se kompletně staral o správu soukromých klíčů. Aplikace by pak data předala spolu s mime typem tomuto démonovi, ten by si zavolal prohlížecí program pro dotyčný mime typ, zobrazil data uživateli atd.

Jinak je to míněno jen jako api pro webové stránky - pokud stránka podpis nebude vyžadovat, jůzr by o něm prakticky neměl vědět. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux)

iQIcBAEBAgAGBQJRwxY7AAoJELElzQAiwz4kF0IP/3GxwrRUTu6h9XfsEkTZVimM X2BN6QzEYFJ9dryU3I/DGcW56aNmAuwjndM9qtK4hp+7gJjgHqgJhn6JEU5DF5te 54/DnxrI25TOLIXE3bFFntkcrd4ZbTYl/h7yvQYf/M8Y+ORVL3ha1Pki4yUJ9ykn N2+h3su3r+kIcBNKiEG+23H3R6AJL3Ah5MxDMBbvu6ZDPDGDGf4FjMLXnXDICkRA UD/fHkUOKegQ5SWA8OkDW0aTmzW9g41Va/4+mzRbsYYoK3G+YtuawboiigZW+IG6 onrx87X6VmvKAm3UksikqkyF/0pcE8ZKUPrdVQHT0DEOchrxZiKVD4xsXs7y7UHV pwHi16tUUlOrBkFCLpT2dHheRiD5mTbkjnfCJbm+xzmn7hJi9PFn5s26ddlUUfjV bolzaS3+hhNEbKPdAjNu88/XtJp+fjfi9ER9ZX5UK0ZqrMvdjhqaYndGAHfg8Xtg GBmp9dcQu1PTSuGPn1U1V8xVkL50E1JhjLe3rdy23Qni6sXsPwXW18quC/xUG4ol TB9ex9GQ6TqZE33p4gpXEZmDERQ+2joARRFV6tX1SaFbjKfIffAcZMJ/llqhLin0 1/1TG+MRKVIpBakBFlZiZ+rdoGwGUMTYlYbSJt86BDb4mqdZ19Q+xBwQHQmemDHi xbCN1EOZwerf85xg0HZY =LVGu -----END PGP SIGNATURE-----

[Franta]

data (xhtml + css: pro opakovatelnou prezentaci a zároveň rozšiřitelnost) k podepsání.

A o tom to je Teď už „jen“ zbývá standardizovat tento formát dat a definovat API (pár metod).

A otázka je, jestli by to mělo být XHTML (+CSS). XHTML je stále hodně zaměřené na prezentaci informace, ne až tolik na sémantiku. Bylo by potřeba podporovat další jmenné prostory, aby ta data mohly mít nějakou strukturu a strojově čitelný význam (a nebyla to zprasenina). To už by bylo lepší, kdyby to bylo obecné XML a k němu XSLT generující nějakou podmnožinu XHTML (+CSS). Uživatel by viděl vygenerované XHTML, to by si zkontroloval a podepsal by vstupní XML dokument a XSLT šablonu (ty by si mohl zkontrolovat volitelně).

[David Jaša]

XHTML je stále hodně zaměřené na prezentaci informace, ne až tolik na sémantiku.

Což je v pořádku. Uživatel podepisuje to co vidí on - co si tam pro zjednodušení (strojovou čitelnost) přidá webový program je jen její problém ...

Bylo by potřeba podporovat další jmenné prostory

který je velmi jednoduše řešitelný právě jmennými prostory.

Pointa: podepisovaná data mají být statická a jednoznačná. XSLT je stejně jako JS turingovsky úplný jazyk, proto bych ho v takovém místě viděl jen velmi nerad.

[Franta]

Když podepíšeš data (XML) i program (XSLT), tak to jednoznačně určuje výstup (XHTML) i když i ten můžeš klidně taky podepsat.

[petr_p]

XSLT má parametry. A parametry lze předat z vnějšího prostředí. A to nemluvím o externím DTD.

[Franta]

Parametry by byly prázdné a externí DTD zakázané (stejně jako volání nestandardních funkcí).

[j]

Uplne jednoduse. Srv by predal prohlizeci to, co mas podepsat a ten by to klientovi zobrazil. V takovym prvku by nefungovalo zadny scriptovani, zadny skryvani, pokrocily stylovani ... A prohlizec by to pro jistotu moh vzit, a klientovi ulozit do archivu v podobe podepsane bitmapy.

[Bubak]

Hm, a kdo mi zaruci, ze ten prvek neni nafixlovanej a podvrzenej? Myslim, ze nejsem sam, kdo by necemu takovemu klic do paratu nedal...

[Václav HFechs Švirga]

To jde zajistit bez problému pomocí modálního dialogu, javascript umožňuje vyskočit jen pár okýnek (alert, confirm), ale neumožňuje jejich stylování. A i kdyby, tak potvrzením falešného dialogu by přece neproběhlo šifrování, to až s potvrzením pravého (nemodifikovatelného -> dělal by ho prohlížeč, ne html + js + css) dialogu .

[mirec]

Občas to nie je potrebné.

[Václav HFechs Švirga]

+1

[mmm]

To je lež, alternativou je zcela standardní JavaScript, který je v každém prohlížeči.

Takový Mega zvládá JavaScriptem šifrovat a dešifrovat celé mnohagigabajtové soubory, vážně si myslíte, že podepisování by byl problém?

[mmm]

Tady třeba hotová JS knihovna:

jsrsasign - opensource free RSA signing/validation, ASN.1, PKCS#5/8 private key X.509 certificate and CRL library in pure JavaScript

[mmm]

Jinak s lokálními soubory se dá pomocí JavaScriptu už dlouho standardizovanou cestou pracovat, viz File API, např.:

Reading files in JavaScript using the File APIs

[Franta]

1. Já ale nechci dát nějakému pochybnému JavaScriptu* staženému bůhví odkud dát svůj soukromý klíč, aby si s ním mohl dělat, co chce (třeba odeslat na server a pak jím podepisovat cokoli mým jménem). Bylo by potřeba JS API pro práci s bezpečnostním zařízením (ať už HW token nebo SW úložiště – byla by tam abstrakce, takže by bylo jedno, co to je), které dostane hash/dokument k podepsání a vrátí podpis (ale nikdy neposkytne samotný klíč).
2. Jak bude uživatel vědět, co přesně podepisuje? Co když HTML formulář/stránka zobrazuje něco jiného, než co JS nakonec nechá podepsat tvým klíčem?

*) tím nemyslím tu knihovnu, ale JS, který mi přijde z webu, který ji používá

[stativ]

A s pochyným java appletem problém nemáš?

[Franta]

Vždyť píšu, že by to měla být svobodná desktopová aplikace.

A vytvářená někým nezávislým – někým jiným, než kdo mě nabádá k jejímu použití (pojišťovny, banky, stát atd.). Takovou aplikaci by měl vyvinout např. někdo z akademické sféry, skupina odborníků + vše pod veřejnou kontrolou.

Java Applet (resp. jakákoli na míru psaná a od daného subjektu stahovaná aplikace) je stejně tak nevhodný jako ten JS. Jde o princip, že ten (resp. jeho SW), kdo po tobě chce nějaký podepsaný dokument, dostane tvůj soukromý klíč – to je zásadní chyba.

[Filip Jirsák]

Nejde o samotné šifrování, ale o přístup k privátnímu klíči. Ten máte v méně bezpečném případě v souboru na disku – a k tomu se přes standardní JavaScript nedostanete (v HTML5 je na to rozšíření, ale to nepodporují všechny prohlížeče). V bezpečnějším případě máte privátní klíč na kartě nebo tokenu a softwarově se k němu vůbec nejde dostat. Pracuje se s ním přes ovladač, kterému pošlete data k zašifrování a vrátí se vám zašifrovaný výsledek. K tomu ovladači se přes JavaScript nedostanete už vůbec nijak.

Takže standardní JavaScript nestačí a tvrzení o Javě jako jediném prakticky použitelném nástroji není lež.

[mmm]

Většina bankovních řešení, které se běžně používají a vyžadují Javu, jí vyžadují právě a jen kvůli tomu podpisovému klíči v souboru na disku. Tohle JavaScript skutečně jednoduše nahradí. To že File API z HTML 5 nepodporují některé staré verze prohlížečů není argument, stejně by byl uživatel nucen nainstalovat Javu (a tím snížit bezpečnost), takhle je nucen nainstalovat jen novější verzi browseru (a tím bezpečnost naopak zvýšit).

Pokud někdo vyžaduje řešení s bezpečnostními klíči na čipové kartě (které samozřejmě je bezpečnější, to nerozporuji), holt se musí s Javou smířit. Ale naprostá většina toto řešení nepoužívá a není tak důvod proč by měli být nuceni instalovat skrz na skrz děravou Javu.

[Franta]

Tohle JavaScript skutečně jednoduše nahradí.

Možná by stálo za to se při tom nahrazování na chvíli zastavit a zamyslet se, jaký má tohle „řešení“ smysl. Kryptografie při takovém použití nemá smysl a stejně dobře by posloužilo jméno a heslo nebo libovolný soubor (plnící funkci dlouhého hesla), který bych jen přiložil k odesílaným datům. Efekt by byl stejný.

[Franta]

P.S. aneb až se s bankou budeš někdy hádat jestli jsi nějaký platební příkaz zadal nebo ne, tohle je úplně na nic. Banka ti mohla soukromý klíč kdykoli v minulosti ukrást a ten příkaz jím teď podepsat. Nikdo už nezjistí, jestli se to stalo nebo ne, jestli příkaz podepsala banka nebo ty. Je to na nic a nemá to o nic vyšší vypovídací hodnotu než když si banka zaloguje do databáze, že ses tehdy a tehdy přihlásil správným jménem a heslem a zadal určitý příkaz.

Funkční by naopak bylo, kdybys měl soukromý klíč, který nemusíš nikdy nikomu dalšímu dát, příkaz jím podepíšeš pomocí softwaru, který sis sám vybral a bance předáš pouze příkaz s podpisem.

[Filip Jirsák]

File API je reálně v prohlížečích dostupné pár měsíců. Java bývala v prohlížečích běžně dostupná, bývala bezúdržbová a bezpečná. Elektronické bankovnictví není aplikace, která se bude každých pár měsíců komplet předělávat podle toho, jaké jsou zrovna módní trendy u webových prohlížečů. Navíc by to byla další komplikace pro uživatele -- pokud máte certifikát v souboru, použijte tohle, pokud na kartě, použijte něco jiného...

Skrz naskrz děravá Java byla otázka několika dnů na jaře, než Oracle vydal záplatu. Ty dnešní opravy pokud vím opravují bezpečnostní díry v Javě, ale ne v zavaděči appletů/JNLP. To znamená, že i s tou děravou Javou by uživatel musel odsouhlasit minimálně spuštění appletu, ne-li zvýšená oprávnění. To znamená, že pouze nainstalovaná Java není nebezpečná, bezpečnostní díru by mohla zneužívat až ta spuštěná bankovní aplikace -- která ale stejně tak může zneužít to File API.

[Jendа]

Sakra, flame, který jsem prošvihl!

Mohl byste prosím popsat nějaký attack vector, kterému podepisování pomocí appletu dodaného službou zabrání?

Diskuzní zkratka: Při posledním flame s vámi na toto téma jste nadhodil:

• že by se musela spiknout skupina zaměstnanců, která dělá applet, a která dělá webové rozhraní
• že uživatel může podvržený applet dokázat

Na první jsem odpověděl, že applety nedělám, ale myslím si, že applet může posílat HTTP požadavky v kontextu stránky, ve které je spuštěn; na druhé, že uživatel by si musel všechny verze bankovních appletů ukládat a v případě problémů zajistit soudní zkoumání několikamegového souboru.

Na tyto argumenty jste již neodpověděl, proto jsem problematiku považoval za vyřízenou. Teď to tu vidím znovu - můžete mě prosím seznámit se změnou situace?

[Jendа]

Funkční odkaz do té diskuze.

[xkucf03]

Ještě než se rozjede další kolo flamu, tak bych rád poznamenal, že je potřeba rozlišovat dva případy:

• JS aplikace stažená společně s webem má přístup k soukromému klíči a sama provádí šifrování nebo podepisování
• klíče jsou uložené na bezpečném místě a JS aplikace k nim nemá přístup – jen volá nějaké funkce prohlížeče

První případ je tragický a kontraproduktivní (falešný pocit bezpečí), kryptografie je zde zcela zbytečná a zavádějící a soukromý klíč plní jen roli jakéhosi dlouhého hesla.

Druhý případ by mohl být užitečný, pokud by ho někdo standardizoval a napsal potřebné nástroje – je to jen otázka vhodného API a GUI.

[bbbb]

Ake je len v mode pindat na bezpecnost javy, ze je to derave a co ja viem co ... Ale vidite, ze sa s tym aspon nieco robi a vychadzaju desiatky oprav a patchov, zda sa mi, ze to zacalo pred nejakym casom, ze sa do toho Oracle tak obul a cisti to ... Co to maju nechat tak? Nerobi sa nic -> zle. Opravuju to, este horsie ...

[washeck]

V první řadě by stačilo, aby ke každé aktualizaci (pro Windows) nepřibalovali malware (konkrétně Ask Toolbar). Je tam sice checkbox, že ho nechceš, ale 1) při rychlé aktualizaci to snadno přehlédneš 2) minule u mě kvůli nějaké chybě tato část dialogu nebyla zobrazena a odškrtnout jsem to nemohl. Odstranit tu sračku ze všech prohlížečů je práce na zbytek dne. Doufám, že java se rychle odebere na stejnou cestu jako flash.

[bbbb]

a aku mas alternativu? JVM tu s nami bude este velmi dlho v roznych podobach, ty by si asi zapichol Javu hned aj so Scalou, Groovy, Closure ... zachvilu sa bude tlacit Ceylon atd. Ja nehovorim, ze Java je nebesky jazyk, ale predstava, "ze java se rychle odebere" je ... mylna?

[Franta]

Je to samozřejmě pitomost. Jestli se někomu nelíbí práce Oraclu, tak může Javu klidně převzít a dělat lépe – je to svobodný software (na rozdíl od sraček typu Flash, Silverlight apod.) a otevřená platforma.

[bbbb]

:) no samozrejme, ako napriklad OpenJDK? Neviem ... ja sa na OpenJDK pozeram ako na Javu druhej kategorie, ked je "bordel" v Oracle Jave, potom si velmi neviem prestavit, co to musi byt v OpenJDK ... Alebo myslis este niekoho uplne noveho?

[David Jaša]

ja sa na OpenJDK pozeram ako na Javu druhej kategorie

A to proč?

[bbbb]

skus si par minut o oracle vs openjdk pogooglit a uvidis aj sam ... ludia mali s openjdk problemy, IDE na tom islo pomalsie, fonty v openjdk bola hroza ... ja viem ze openjdk je referencna implementacia ale ja asi verim viac oracle jak open source (ano, ukrizujte ma za to :D)

[washeck]

Teoreticky ano, ale v praxi většina aplikací, na které jsem narazil, vyžadovala nejen oficiální Javu, ale někdy i konkrétní verzi (viz též Maxův komentář). Nevěřím, že rozumně použitelná alternativní reimplementace něčeho tak rozsáhlého v dohledné době vznikne a proto spíš doufám v postupný útlum celé platformy.

[Franta]

Proč by proboha měla vznikat alternativní reimplementace, když máš od všeho zdrojáky a rozumnou licenci?? S útlumem běž do háje, nevíš, o čem mluvíš.

[washeck]

Máš pravdu, že o Javě moc nevím, nezajímá mě. Na klientovi jsem java aplet neviděl už hodně dlouho (v tom spatřuju ten útlum) a na serveru potřebuju jedinou javovou aplikaci a to Geoserver. A ten, když jsem naposledy (cca 2 roky zpátky) zkoumal, uváděl, že s OpenJDK nefunguje. Teď jsem si dohledal, že šlo o chybu v dokumentaci (http://jira.codehaus.org/browse/GEOS-4365), ale na druhou stranu, když se v tom nevyznají ani javisti, necítím to jako zásadní neznalost.

[Honza Jaroš]

Odstranit tu sračku ze všech prohlížečů je práce na zbytek dne.

Tohle jsem tu zahlédl už dřív - on u toho už nefunguje odinstalátor? Mně zatím vždycky, když jsem na tuhle mrchu u někoho narazil, stačilo otevřít v Ovládacích panelech panel pro odebrání programů a ty dvě položky týkající se Ask Toolbaru prostě odinstalovat...

[washeck]

Plus po odinstalování projít všechny prohlížeče a změnit home page, odebrat vyhledávací add-on a nastavit zpátky Google (návod). Prostě ideální způsob, jak propagovat javu jako důvěryhodnou platformu.

[Honza Jaroš]

No nevím, nevybavuju si, že bych po odinstalování musel měnit homepage a vyhledávání, ale na druhou stranu dělal jsem to jen párkrát a už je to nějaká doba, takže ruku do ohně bych za to nedal. Tak jako tak pod pojmem "práce na zbytek dne" si představuju něco jiného, já to měl na pár kliknutí myši.

Nicméně souhlasím s tím, že ten šmejd nemá v instalaci Javy co dělat a Oraclu asi šibe, když to přibaluje (a navíc takhle debilním způsobem)...

[Max]

Jojo, už jsme dostali maila od Němců, abychom na javu 7u25 neaktualizovali, že v tom nejede jejich webová aplikace. Heh.
Zdar Max