Možno ste počuli o najnovšej chybe v zabezpečení JDK 1.1 a HotJava 1.0, ktorú nedávno objavil tím Secure Internet Programming na Princetonskej univerzite (vedený jedným z autorov). Ak chcete celý príbeh, čítajte ďalej. Zabezpečenie Java však obsahuje viac než špecifiká tejto najnovšej bezpečnostnej diery. Poďme si urobiť nejakú perspektívu.
Bezpečnosť Java a vnímanie verejnosti
Každý vie, že bezpečnosť je pre Java veľká vec. Kedykoľvek sa objaví bezpečnostná diera, príbeh sa rýchlo vrhne do počítačových správ (a niekedy aj do obchodných správ). Možno vás neprekvapí zistenie, že populárna tlač sleduje komp. riziká a ďalšie diskusné skupiny súvisiace s bezpečnosťou. Vyberajú bezpečnostné príbehy, ktoré zvýrazňujú zdanlivo náhodne. Aj keď je dnes Java tak horúca, takmer vždy tlačia bezpečnostné príbehy z Java.
Problém je v tom, že väčšina novinových správ vôbec nevysvetľuje diery dobre. To by mohlo viesť k klasickému problému „plačúceho vlka“, keď si ľudia zvyknú pozerať „bezpečnostný príbeh tohto týždňa“ a nevychovávajú sa o skutočných rizikách spustiteľného obsahu. Predajcovia majú navyše tendenciu bagatelizovať svoje problémy so zabezpečením, čo ďalej zamieňa kľúčové problémy.
Dobrá správa je, že bezpečnostný tím JavaSoft to so zabezpečením Java myslí vážne. Zlou správou je, že väčšina vývojárov a používateľov Java môže uveriť humbuku pochádzajúcemu z udalostí ako JavaOne, kde sa bezpečnostným problémom príliš nehovorí. Ako sme povedali v našej knihe, Zabezpečenie Java: nepriateľské applety, diery a protilátky, Sun Microsystems môže veľa získať, ak vás presvedčí, že Java je úplne bezpečná. Je pravda, že predajcovia vyvinuli maximálne úsilie, aby boli ich implementácie Java čo najbezpečnejšie, vývojári však nechcú úsilie; chcú výsledky.
Pretože webový prehľadávač s podporou jazyka Java umožňuje vloženie kódu Java do webovej stránky, stiahnutie cez sieť a spustenie na lokálnom počítači, je bezpečnosť zásadným problémom. Používatelia si môžu Java applety sťahovať s mimoriadnou ľahkosťou - niekedy aj bez toho, aby o tom vedeli. Toto vystavuje používateľov Javy značnému riziku.
Dizajnéri Java sú si dobre vedomí mnohých rizík spojených so spustiteľným obsahom. Aby bojovali proti týmto rizikám, navrhli program Java špeciálne s ohľadom na bezpečnostné problémy. Hlavným cieľom bolo čeliť otázkam bezpečnosti čelne, aby sa naivní používatelia (povedzme väčšina z miliónov surfujúcich po webe) nemuseli stať bezpečnostnými expertmi, aby mohli bezpečne prehliadať web. To je obdivuhodný cieľ.
Tri časti karantény Java
Java je veľmi silný vývojový jazyk. Nedôveryhodným appletom by nemal byť povolený prístup k celej tejto sile. Sandbox Java obmedzuje applety vo vykonávaní mnohých činností. Najlepším technickým dokumentom o obmedzeniach appletov je „Nízka úroveň zabezpečenia v Jave“ od Franka Yellina.
Zabezpečenie Java sa spolieha na tri hroty obrany: Byte Code Verifier, Class Loader a Security Manager. Tieto tri hroty spoločne vykonávajú kontroly načítania a chodu s cieľom obmedziť prístup k súborovému systému a sieti, ako aj prístup k vnútorným častiam prehliadača. Každý z týchto hrotov nejakým spôsobom závisí od ostatných. Aby bezpečnostný model správne fungoval, musí každá časť vykonávať svoju prácu správne.
Overovateľ bajtového kódu:
Byte Code Verifier je prvý hrot bezpečnostného modelu Java. Keď je kompilovaný zdrojový program Java, kompiluje sa na bajtový kód Java nezávislý na platforme. Bajtový kód Java je pred spustením „overený“. Účelom tejto overovacej schémy je zabezpečiť, aby sa bajtový kód, ktorý mohol alebo nemusel vytvoriť kompilátor Java, prehral podľa pravidiel. Bajtový kód koniec koncov mohol dobre vytvoriť „nepriateľský kompilátor“, ktorý zostavil bajtový kód navrhnutý na zlyhanie virtuálneho stroja Java. Overenie bajtového kódu appletu je jedným zo spôsobov, ako Java automaticky kontroluje nedôveryhodný vonkajší kód pred tým, ako sa nechá bežať. Overovač kontroluje bajtový kód na mnohých rôznych úrovniach. Najjednoduchší test zaručuje, že formát fragmentu bajtového kódu je správny. Na menej základnej úrovni sa na každý fragment kódu použije vstavaný tester viet. Dôkaz vetou pomáha zaistiť, aby bajtový kód nezfalšoval ukazovatele, neporušoval obmedzenia prístupu alebo nepristupoval k objektom pomocou nesprávnych informácií o type. Proces overovania, v zhode s bezpečnostnými prvkami zabudovanými do jazyka prostredníctvom kompilátora, pomáha ustanoviť základnú sadu bezpečnostných záruk.
Zavádzač triedy appletov:
Druhým hrotom bezpečnostnej obrany je Java Applet Class Loader. Všetky objekty Java patria do tried. Aplikácia Classet Loader určuje, kedy a ako môže applet pridať triedy do spusteného prostredia Java. Súčasťou jeho práce je zabezpečiť, aby dôležité časti run-time prostredia Java neboli nahradené kódom, ktorý sa pokúša nainštalovať applet. Všeobecne platí, že v bežiacom prostredí Java môže byť aktívnych veľa Class Loaders, z ktorých každý definuje svoj vlastný „priestor mien“. Menné priestory umožňujú rozdelenie tried Java na rôzne „druhy“ podľa toho, odkiaľ pochádzajú. Načítavač tried appletov, ktorý zvyčajne dodáva dodávateľ prehliadača, načíta všetky applety a triedy, na ktoré odkazujú. Keď sa applet načíta cez sieť, načítač triedy appletov prijme binárne údaje a vytvorí z nich inštanciu ako novú triedu.
Bezpečnostný manažér:
Tretím bodom bezpečnostného modelu Java je Java Security Manager. Táto časť bezpečnostného modelu obmedzuje spôsoby, akými môže applet používať viditeľné rozhrania. Správca zabezpečenia teda implementuje značnú časť celého modelu zabezpečenia. Security Manager je jediný modul, ktorý môže vykonávať kontroly za behu „nebezpečných“ metód. Kód v knižnici Java konzultuje s programom Security Manager vždy, keď sa chystá pokus o nebezpečnú operáciu. Správca zabezpečenia dostane šancu vetovať operáciu vygenerovaním bezpečnostnej výnimky (prekliatie vývojárov Java všade). Rozhodnutia vykonané správcom bezpečnosti berú do úvahy, ktorý Class Loader načítal požadujúcu triedu. Vstavané triedy majú väčšie privilégium ako triedy, ktoré boli načítané cez sieť.
Nedôverčivý a vykázaný na pieskovisko
Tieto tri časti bezpečnostného modelu Java spolu tvoria pieskovisko. Cieľom je obmedziť, čo môže applet robiť, a zabezpečiť, aby hrala podľa pravidiel. Myšlienka pieskoviska je príťažlivá, pretože má umožniť prevádzku nedôveryhodný kód na vašom počítači bez obáv. Takto môžete beztrestne surfovať po webe a bez problémov so zabezpečením spúšťať každý applet Java, na ktorý ste kedy narazili. Pokiaľ však karanténa Java nemá bezpečnostné diery.
Alternatíva k pieskovisku:
Autentifikácia prostredníctvom podpisovania kódu
ActiveX je ďalšia vysoko profilovaná forma spustiteľného obsahu. Program ActiveX propagovaný spoločnosťou Microsoft bol kritizovaný profesionálmi v oblasti počítačovej bezpečnosti, ktorí považujú jeho prístup k bezpečnosti za nedostatočný. Na rozdiel od bezpečnostnej situácie v prostredí Java, keď je applet obmedzený softvérovým ovládaním na to, čo dokáže, ovládací prvok ActiveX nemá po vyvolaní žiadne obmedzenia svojho správania. Výsledkom je, že používatelia prvkov ActiveX musia byť veľmi opatrní, aby mohli bežať iba úplne dôveryhodný kód. Používatelia Java majú na druhej strane ten luxus, že môžu nedôveryhodný kód bežať bezpečne.
Prístup ActiveX sa spolieha na digitálne podpisy, druh šifrovacej technológie, v ktorej môže vývojár alebo distribútor „podpisovať“ ľubovoľné binárne súbory. Pretože digitálny podpis má špeciálne matematické vlastnosti, je neodvolateľný a neodpustiteľný. To znamená, že program, ako je váš prehliadač, môže overiť podpis, vďaka čomu budete mať istotu, kto sa za tento kód zaručil. (Prinajmenšom to je teória. V skutočnom živote sú veci trochu nejednoznačné.) Ešte lepšie je, ak nastavíte prehliadaču pokyn, aby vždy akceptoval kód podpísaný stranou, ktorej dôverujete, alebo vždy odmietol kód podpísaný stranou, ktorej dôverujete nedôveruj.
Digitálny podpis obsahuje veľa informácií. Môže vám napríklad povedať, že aj keď nejaký kód redistribuuje stránka, ktorej nedôverujete, pôvodne ju napísal niekto, komu dôverujete. Alebo vám môže povedať, že hoci kód napísal a distribuoval niekto, koho nepoznáte, váš priateľ ho podpísal a potvrdil tak, že je bezpečný. Alebo vám jednoducho povie, ktorý z tisícov používateľov je u aol.com napísal kód.
(Viac podrobností o digitálnych signitúrach vrátane piatich kľúčových vlastností nájdete na bočnom paneli.)
Budúcnosť spustiteľného obsahu: Opustenie karantény
Vďaka digitálnym podpisom je technológia ActiveX bezpečnejšia z hľadiska bezpečnosti ako Java? Veríme, že nie, najmä vzhľadom na skutočnosť, že funkcia digitálneho podpisu je teraz k dispozícii v JDK 1.1.1 Java (spolu s ďalšími vylepšeniami zabezpečenia). To znamená, že v prostredí Java získate všetko, čo ActiveX robí pre bezpečnosť plus schopnosť pomerne spoľahlivo spustiť nedôveryhodný kód. Zabezpečenie Java bude v budúcnosti ešte viac vylepšené flexibilnou a precíznou kontrolou prístupu, ktorá je podľa Li Gonga, bezpečnostného architekta Java Java, naplánovaná na vydanie v JDK 1.2. Lepšia kontrola prístupu sa dostane aj do ďalšieho kola prehľadávačov vrátane Netscape Communicator a MicroSoft Internet Explorer 4.0.
Spolu s kontrolou prístupu bude podpisovanie kódu umožňovať appletom postupovať postupne mimo bezpečnostnú karanténu. Napríklad applet určený na použitie v prostredí intranetu by mohol mať povolené čítať a písať do a najmä databázu spoločnosti, pokiaľ ju podpísal správca systému. Takéto uvoľnenie bezpečnostného modelu je dôležité pre vývojárov, ktorí sa trochu snažia dosiahnuť, aby ich applety mohli robiť viac. Písanie kódu, ktorý funguje v rámci prísnych obmedzení karantény, je bolesť. Pôvodné pieskovisko je veľmi obmedzujúce.
Nakoniec budú mať applety povolené rôzne úrovne dôveryhodnosti. Pretože to vyžaduje kontrolu prístupu, odtiene dôveryhodnosti momentálne nie sú k dispozícii, aj keď je to prihlasovanie kódu. V súčasnej podobe v JDK 1.1.1 sú applety Java buď úplne dôveryhodné, alebo úplne nedôveryhodné. Podpísaný applet označený ako dôveryhodný môže úplne uniknúť z karantény. Takýto applet môže robiť vôbec všetko a má žiadne bezpečnostné obmedzenia.
Hlavným problémom prístupu Javy k bezpečnosti je jej komplikovanosť. Komplikované systémy majú tendenciu mať viac nedostatkov ako jednoduché systémy. Vedci v oblasti bezpečnosti, predovšetkým tím zabezpečeného programovania na internete v Princetone, zistili v prvých verziách karantény niekoľko závažných bezpečnostných chýb. Mnoho z týchto nedostatkov boli chyby implementácie, ale niektoré boli chyby špecifikácie. Našťastie programy JavaSoft, Netscape a Microsoft veľmi rýchlo napravili takéto problémy, keď sa objavia. (Jasné a úplné vysvetlenie bezpečnostných dier v Jave nájdete v kapitole 3 našej knihy.)
Len nedávno obchodníci zo Slnka (niekedy nazývaní evanjelisti) rýchlo poukazovali na to, že za nejaký čas neboli objavené žiadne nové nedostatky. Brali to ako dôkaz, že Java už nikdy nebude trpieť bezpečnostnými problémami. Skočili z pištole.
Otvor na podpisovanie kódu: Java si vytvára koleno
Podpisovanie kódu je komplikované. Rovnako ako v pôvodnom modeli karantény, aj pri navrhovaní a implementácii systému na podpisovanie kódu existuje veľa priestoru pre chyby. Nedávna diera bola dosť priamym problémom pri implementácii Java Trieda triedy, ako je vysvetlené na stránke Princeton aj na bezpečnostnej stránke JavaSoft. Konkrétne metóda Class.getsigners () vráti premenlivé pole všetkých signatárov známych systému. Je možné, že applet tieto informácie zneužije. Oprava bola taká jednoduchá, ako vrátiť iba kópiu poľa a nie samotné pole.
Zvážte situáciu, v ktorej vývojárovi Alice nebolo udelené žiadne bezpečnostné privilégium v systéme používateľa webu. V skutočnosti, na rozdiel od toho, čo tvrdilo pôvodné vyhlásenie JavaSoft o chybe, Alice môže byť systému úplne neznámy. Inými slovami, kódu, ktorý podpísala Alice, sa nedôveruje o nič viac ako obvyklý applet na ulici. Ak používateľ webu (pomocou prehliadača HotJava - v súčasnosti jediný komerčný produkt, ktorý podporuje JDK 1.1.1) načíta applet podpísaný Alice, tento applet môže stále vystúpiť z karantény využitím otvoru.
Skutočnosť, že systém nemusí mať vo svojej databáze Alicin verejný kľúč, je dôležitá. Znamená to, že Alice môže byť ľubovoľný útočník, ktorý vie, ako podpísať applet so úplne náhodnou identitou. Vytvorenie takejto identity je ľahké, rovnako ako podpísanie appletu s touto identitou. Vďaka tomu je diera skutočne veľmi vážna.
Diera umožňuje Alicinmu útočnému appletu zmeniť predstavu systému o tom, kto ho podpísal. To je obzvlášť zlé, ak Alice nemá oprávnenie bežať mimo karantény, ale Bob áno. Alicin applet môže používať getigners () volanie zmeniť jeho úroveň povolenia tak, aby zahŕňal všetky Bobove privilégiá. Alicin applet môže získať maximálne množstvo dostupných privilégií rozdelených na akýkoľvek signatár známy systému.
Ak priradíte identitu podpisu / privilégia k kabátom v skrini, Alicin útočný applet môže vyskúšať každý kabát a vyskúšať rôzne nepovolené veci, kým nezistí, ktoré z kabátov sú „kúzelné“, a umožniť im získať privilégium. Ak sa objaví čarovný kabát, Alicin applet môže vystúpiť z pieskoviska a robiť veci, ktoré by nemali mať povolené. Skúšanie kabátov je také jednoduché ako pokus o nepovolený hovor a sledovanie, čo sa stane.
