Možná jste slyšeli o nejnovější chybě zabezpečení JDK 1.1 a HotJava 1.0, kterou nedávno objevil tým Secure Internet Programming na Princetonské univerzitě (vedený jedním z autorů). Pokud chcete celý příběh, čtěte dále. Zabezpečení Java má ale víc než specifika této nejnovější bezpečnostní díry. Pojďme se podívat na nějakou perspektivu.
Zabezpečení Java a vnímání veřejnosti
Každý ví, že bezpečnost je pro Javu velká věc. Kdykoli je objevena bezpečnostní díra, příběh se rychle vrhne do počítačových zpráv (a někdy i obchodních zpráv). Možná vás nepřekvapí, že populární tisk sleduje komp. rizika a další diskusní skupiny související se zabezpečením. Vybírají příběhy zabezpečení, aby je zdánlivě náhodně zvýraznili, i když je dnes Java tak horká, že téměř vždy tisknou příběhy zabezpečení Java.
Problém je v tom, že většina novinek vůbec nevysvětluje tyto mezery. To by mohlo vést ke klasickému problému „plačícího vlka“, kdy si lidé zvyknou vidět „bezpečnostní příběh tohoto týdne“ a nevychovávají se o skutečných rizicích spustitelného obsahu. Dodavatelé mají navíc tendenci bagatelizovat své bezpečnostní problémy, a tak dále matou klíčové problémy.
Dobrou zprávou je, že bezpečnostní tým JavaSoft to myslí se zabezpečením Java vážně. Špatnou zprávou je, že většina vývojářů a uživatelů Java může uvěřit humbuku vycházejícímu z událostí, jako je JavaOne, kde bezpečnostní problémy nejsou příliš vzdušné. Jak jsme řekli v naší knize, Zabezpečení Java: Nepřátelské applety, díry a protilátky Sun Microsystems má co získat, pokud vás přesvědčuje, že je Java zcela bezpečná. Je pravda, že prodejci se velmi snažili, aby jejich implementace Java byla co nejbezpečnější, ale vývojáři nechtějí úsilí; chtějí výsledky.
Jelikož webový prohlížeč s podporou jazyka Java umožňuje vložení kódu Java na webovou stránku, stažení přes síť a spuštění na místním počítači, je bezpečnost zásadním problémem. Uživatelé si mohou stáhnout applety Java s výjimečnou lehkostí - někdy i bez toho, aby o tom věděli. To vystavuje uživatele Java značnému riziku.
Návrháři Java si jsou dobře vědomi mnoha rizik spojených se spustitelným obsahem. V rámci boje proti těmto rizikům vytvořili prostředí Java speciálně s ohledem na bezpečnostní problémy. Hlavním cílem bylo čelit problému zabezpečení tak, aby se naivní uživatelé (řekněme většina z milionů webových surfařů) nemuseli stát bezpečnostními experty, aby mohli bezpečně prohlížet web. To je obdivuhodný cíl.
Tři části karantény Java
Java je velmi silný vývojový jazyk. Nedůvěryhodným appletům by neměl být umožněn přístup k celé této moci. Sandbox Java omezuje applety v provádění mnoha činností. Nejlepším technickým dokumentem o omezeních appletů je „Nízká úroveň zabezpečení v Javě“ od Franka Yellina.
Zabezpečení Java závisí na třech bodech obrany: Byte Code Verifier, Class Loader a Security Manager. Společně tyto tři hroty provádějí kontroly načítání a běhu, aby omezily přístup k systému souborů a síti a také přístup k interním stránkám prohlížeče. Každý z těchto hrotů určitým způsobem závisí na ostatních. Aby model zabezpečení správně fungoval, musí každá část dělat svou práci správně.
Ověření bytového kódu:
Bajtový ověřovač kódu je prvním hrotem bezpečnostního modelu Java. Když je kompilován zdrojový program Java, kompiluje se na bajtový kód Java nezávislý na platformě. Bajtový kód Java je před spuštěním „ověřen“. Toto ověřovací schéma má zajistit, že bajtový kód, který může nebo nemusí být vytvořen kompilátorem Java, se hraje podle pravidel. Koneckonců, bytový kód mohl být dobře vytvořen „nepřátelským kompilátorem“, který sestavil bytový kód navržený tak, aby havaroval virtuální stroj Java. Ověření bytového kódu appletu je jedním ze způsobů, jak Java automaticky kontroluje nedůvěryhodný vnější kód před tím, než je povoleno spustit. Ověřovatel kontroluje bajtový kód na několika různých úrovních. Nejjednodušší test zajišťuje, že formát fragmentu bajtového kódu je správný. Na méně základní úrovni se na každý fragment kódu použije vestavěný tester vět. Věta prover pomáhá zajistit, aby bajtový kód nezfalšoval ukazatele, neporušoval omezení přístupu nebo nepřistupoval k objektům pomocí nesprávných informací o typu. Proces ověřování ve shodě s bezpečnostními funkcemi zabudovanými do jazyka prostřednictvím kompilátoru pomáhá vytvořit základní sadu bezpečnostních záruk.
Zavaděč třídy appletů:
Druhým hrotem bezpečnostní ochrany je Java Applet Class Loader. Všechny objekty Java patří do tříd. Zavaděč tříd appletů určuje, kdy a jak může applet přidávat třídy do běžícího prostředí Java. Součástí jeho práce je zajistit, aby důležité části běhového prostředí Java nebyly nahrazeny kódem, který se pokusí nainstalovat applet. Obecně platí, že v běžícím prostředí Java může být aktivních mnoho Class Loaderů, z nichž každý definuje svůj vlastní „jmenný prostor“. Názvové prostory umožňují rozdělení tříd Java do odlišných „druhů“ podle toho, odkud pocházejí. Zavaděč tříd appletů, který obvykle dodává prodejce prohlížeče, načte všechny applety a třídy, na které odkazují. Když se applet načte po síti, zavaděč tříd appletů přijme binární data a vytvoří z nich instanci nové třídy.
Správce zabezpečení:
Třetím bodem bezpečnostního modelu Java je Java Security Manager. Tato část modelu zabezpečení omezuje způsoby, kterými může applet používat viditelná rozhraní. Správce zabezpečení tedy implementuje velkou část celého modelu zabezpečení. Security Manager je jediný modul, který může provádět kontroly běhu „nebezpečných“ metod. Kód v knihovně Java konzultuje správce zabezpečení, kdykoli se chystáte provést nebezpečnou operaci. Správce zabezpečení má šanci vetovat operaci generováním bezpečnostní výjimky (zhouba vývojářů Java všude). Rozhodnutí provedená správcem zabezpečení berou v úvahu, který Class Loader načetl požadující třídu. Integrovaným třídám je přiděleno větší oprávnění než třídám, které byly načteny přes síť.
Nedůvěryhodný a vykázaný na pískoviště
Společně tvoří tři části bezpečnostního modelu Java sandbox. Cílem je omezit, co může applet dělat, a zajistit, aby hrál podle pravidel. Myšlenka izolovaného prostoru je lákavá, protože vám má umožnit běh nedůvěryhodný kód na vašem počítači bez obav z toho. Tímto způsobem můžete beztrestně surfovat po webu a bez problémů se zabezpečením spouštět všechny Java applety, které jste kdy narazili. No, pokud karanténa Java nemá žádné bezpečnostní otvory.
Alternativa k pískovišti:
Ověřování pomocí podepisování kódu
ActiveX je další vysoce profilovaná forma spustitelného obsahu. Technologie ActiveX propagovaná společností Microsoft byla kritizována odborníky na počítačovou bezpečnost, kteří považují její přístup k zabezpečení za nedostatečný. Na rozdíl od bezpečnostní situace v Javě, kdy je applet omezen softwarovým ovládáním v tom, co dokáže, ovládací prvek ActiveX nemá po svém vyvolání žádná omezení svého chování. Výsledkem je, že uživatelé ActiveX musí být velmi opatrní, aby spouštěli pouze zcela důvěryhodný kód. Uživatelé Java mají naopak luxus spravovat nedůvěryhodný kód poměrně bezpečně.
Přístup ActiveX se opírá o digitální podpisy, což je druh šifrovací technologie, ve které může vývojář nebo distributor „podepisovat“ libovolné binární soubory. Protože digitální podpis má speciální matematické vlastnosti, je neodvolatelný a neodpustitelný. To znamená, že program, jako je váš prohlížeč, může ověřit podpis, takže si můžete být jisti, kdo za kód ručil. (Alespoň taková je teorie. Ve skutečném životě jsou věci trochu nejednoznačné.) Ještě lépe můžete svému prohlížeči doporučit, aby vždy přijímal kód podepsaný nějakou stranou, které důvěřujete, nebo aby vždy odmítl kód podepsaný jinou stranou, které vy nedůvěřuj.
Digitální podpis obsahuje spoustu informací. Může vám například říci, že i když je nějaký kód redistribuován webem, kterému nedůvěřujete, původně jej napsal někdo, komu důvěřujete. Nebo vám může říci, že ačkoli byl kód napsán a distribuován někým, koho neznáte, váš přítel jej podepsal a potvrzuje, že je bezpečný. Nebo vám jednoduše řekne, který z tisíců uživatelů je na aol.com napsal kód.
(Další podrobnosti o digitálních signiturách, včetně pěti klíčových vlastností, najdete na postranním panelu.)
Budoucnost spustitelného obsahu: Opuštění izolovaného prostoru
Díky digitálním podpisům je ActiveX z hlediska bezpečnosti atraktivnější než Java? Věříme, že ne, zejména s ohledem na skutečnost, že funkce digitálního podpisu je nyní k dispozici v JDK 1.1.1 Java (spolu s dalšími vylepšeními zabezpečení). To znamená, že v Javě získáte vše, co ActiveX dělá pro zabezpečení Plus schopnost spustit nedůvěryhodný kód poměrně bezpečně. Zabezpečení prostředí Java bude v budoucnu ještě dále vylepšeno flexibilním a jemným řízením přístupu, které je podle Li Gonga, bezpečnostního architekta prostředí Java Java, plánováno na vydání v JDK 1.2. Lepší kontrola přístupu se dostane také do dalšího kola prohlížečů, včetně Netscape Communicator a MicroSoft Internet Explorer 4.0.
Ve shodě s kontrolou přístupu podepisování kódu umožní appletům postupně vystoupit mimo bezpečnostní karanténu. Například appletu určenému pro použití v nastavení intranetu lze povolit číst a zapisovat do konkrétní databáze společnosti, pokud byla podepsána správcem systému. Takové uvolnění bezpečnostního modelu je důležité pro vývojáře, kteří se trochu snaží, aby jejich applety dokázaly více. Psaní kódu, který funguje v rámci přísných omezení karantény, je bolest. Původní karanténa je velmi omezující.
Nakonec budou applety povoleny různé úrovně důvěryhodnosti. Protože to vyžaduje řízení přístupu, odstíny důvěryhodnosti aktuálně nejsou k dispozici, i když je podepsání kódu. Jak v současné době stojí v JDK 1.1.1, jsou applety Java buď zcela důvěryhodné, nebo zcela nedůvěryhodné. Podepsaný applet označený jako důvěryhodný může zcela opustit karanténu. Takový applet může dělat cokoli a má žádná bezpečnostní omezení.
Hlavním problémem přístupu Javy k zabezpečení je, že je komplikovaný. Komplikované systémy mají tendenci mít více nedostatků než jednoduché systémy. Výzkumníci v oblasti bezpečnosti, zejména tým Princeton's Secure Internet Programming, našli v raných verzích karantény několik závažných bezpečnostních nedostatků. Mnoho z těchto nedostatků byly chyby implementace, ale některé byly chyby specifikace. Naštěstí JavaSoft, Netscape a Microsoft velmi rychle řešily takové problémy, když byly objeveny. (Jasné a úplné vysvětlení bezpečnostních děr v Javě najdete v kapitole 3 naší knihy.)
Právě nedávno marketeři Slunce (někdy nazývaní evangelisté) rychle poukazovali na to, že za nějakou dobu nebyly objeveny žádné nové nedostatky. Vzali to jako důkaz, že Java už nikdy nebude trpět bezpečnostními problémy. Skočili na zbraň.
Otvor pro podepisování kódu: Java si sklouzává koleno
Podepisování kódu je komplikované. Stejně jako v původním modelu izolovaného prostoru existuje spousta prostoru pro chyby při navrhování a implementaci systému podepisování kódu. Nedávná díra byla při implementaci Java poměrně přímým problémem Třída třídy, jak je vysvětleno jak na webu Princeton, tak na webu zabezpečení JavaSoft. Konkrétně metoda Class.getsigners () vrátí proměnlivé pole všech signatářů známých systému. Je možné, že applet tyto informace zneužije. Oprava byla stejně jednoduchá jako vrácení pouze kopie pole, nikoli samotného pole.
Zvažte situaci, ve které vývojářce Alici nebylo v systému uživatele webu uděleno žádné bezpečnostní oprávnění. Ve skutečnosti, na rozdíl od toho, co tvrdilo původní prohlášení JavaSoft o chybě, Alice může být systém zcela neznámý. Jinými slovy, kód podepsaný Alicí není důvěryhodný o nic víc než obvyklý applet z ulice. Pokud uživatel webu (pomocí prohlížeče HotJava - aktuálně jediného komerčního produktu, který podporuje JDK 1.1.1) načte applet podepsaný Alicí, může tento applet stále vystoupit z karantény využitím otvoru.
Skutečnost, že systém nemusí mít ve své databázi veřejný klíč Alice, je důležitá. To znamená, že Alice může být libovolný útočník, který ví, jak podepsat applet se zcela náhodnou identitou. Vytvoření takové identity je snadné, stejně jako podepsání appletu s touto identitou. Díky tomu je díra opravdu velmi vážná.
Díra umožňuje Aliceho útočnému appletu změnit představu systému o tom, kdo jej podepsal. To je obzvláště špatné, pokud Alice nemá oprávnění k běhu mimo karanténu, ale Bob ano. Alicin applet může používat getsigners () volání ke změně úrovně oprávnění tak, aby zahrnovala všechna Bobova oprávnění. Alicin applet může získat maximální množství dostupných oprávnění přidělených na jakýkoli signatář známý systému.
Pokud přirovnáte identitu podpisu / privilegia k kabátům ve skříni, Alicin útočný applet může vyzkoušet každý kabát a pokusit se o různé nepovolené věci, dokud nezjistí, které z kabátů jsou „magické“, a umožnit jim získat privilegia. Pokud je objeven magický kabát, Alicin applet může vystoupit z pískoviště a dělat věci, které by neměly mít dovoleno. Pokus o kabáty je stejně jednoduchý jako pokus o nepovolený hovor a sledování, co se stane.
