Du har kanskje hørt om den siste feilen i sikkerheten til JDK 1.1 og HotJava 1.0 som nylig ble oppdaget av Secure Internet Programming-teamet ved Princeton University (ledet av en av forfatterne). Hvis du vil ha hele historien, kan du lese videre. Men det er mer med Java-sikkerhet enn detaljene om dette siste sikkerhetshullet. La oss få litt perspektiv.
Java-sikkerhet og offentlig oppfatning
Alle vet at sikkerhet er en stor avtale for Java. Hver gang et sikkerhetshull blir oppdaget, sprenger historien veldig raskt inn i datanyhetene (og noen ganger forretningsnyhetene). Du blir kanskje ikke overrasket over å høre at den populære pressen overvåker komp.risiko og andre sikkerhetsrelaterte nyhetsgrupper. De velger sikkerhetshistorier for å fremheve tilsynelatende tilfeldig, men siden Java er så varmt i disse dager, skriver de nesten alltid ut Java-sikkerhetshistorier.
Problemet er at de fleste nyhetshistorier ikke forklarer hullene godt i det hele tatt. Dette kan føre til et klassisk "gråtulv" -problem der folk blir vant til å se "denne ukens sikkerhetshistorie" og ikke utdanner seg om de veldig reelle risikoen ved kjørbart innhold. Videre har leverandører en tendens til å bagatellisere sine sikkerhetsproblemer, og forvirre nøkkelproblemene ytterligere.
Den gode nyheten er at JavaSoft-sikkerhetsteamet er seriøst med å gjøre Java sikker. Den dårlige nyheten er at et flertall av Java-utviklere og brukere kan tro hypen som kommer fra hendelser som JavaOne der sikkerhetsproblemer ikke blir gitt mye airplay. Som vi sa i boka vår, Java-sikkerhet: fiendtlige applets, hull og motgift, Sun Microsystems har mye å hente hvis det får deg til å tro at Java er helt sikker. Det er sant at leverandørene har strukket seg langt for å gjøre Java-implementeringene så sikre som mulig, men utviklere ønsker ikke innsats; de vil ha resultater.
Siden en Java-aktivert nettleser tillater at Java-kode integreres i en webside, lastes ned over nettet og kjøres på en lokal maskin, er sikkerhet en kritisk bekymring. Brukere kan laste ned Java-appletter med eksepsjonell letthet - noen ganger uten å vite det. Dette utsetter Java-brukere for en betydelig risiko.
Java-designere er godt klar over de mange risikoene forbundet med kjørbart innhold. For å bekjempe disse risikoene, designet de Java spesielt med tanke på sikkerhetshensyn. Hovedmålet var å adressere sikkerhetsproblemet på en slik måte at naive brukere (for eksempel et flertall av de millioner av surfere) ikke trenger å bli sikkerhetseksperter bare for å trygt lese på nettet. Dette er et beundringsverdig mål.
De tre delene av Java-sandkassen
Java er et veldig kraftig utviklingsspråk. Ikke-klarerte appletter skal ikke få tilgang til all denne kraften. Java-sandkassen begrenser applikasjoner fra å utføre mange aktiviteter. Det beste tekniske dokumentet om appletbegrensninger er "Low Level Security in Java" av Frank Yellin.
Java-sikkerhet er avhengig av tre forsvarsdeler: Byte Code Verifier, Class Loader og Security Manager. Tilsammen utfører disse tre tappene last- og kjøretidskontroller for å begrense tilgang til filsystem og nettverk, samt tilgang til nettleserens interne. Hver av disse tappene avhenger på en eller annen måte av de andre. For at sikkerhetsmodellen skal fungere skikkelig, må hver del gjøre jobben sin skikkelig.
Byte-kodeverifisereren:
Byte Code Verifier er den første spissen i Java-sikkerhetsmodellen. Når et Java-kildeprogram er kompilert, kompileres det ned til plattformuavhengig Java-byte-kode. Java-byte-kode er "verifisert" før den kan kjøres. Denne verifiseringsskjemaet er ment å sikre at byte-koden, som kanskje eller ikke har blitt opprettet av en Java-kompilator, spiller etter reglene. Tross alt kunne bytekode godt ha blitt opprettet av en "fiendtlig kompilator" som samlet bytekode designet for å krasje den virtuelle Java-maskinen. Verifisering av applets byte-kode er en måte som Java automatisk sjekker utrovert utenfor-kode før den får løpe. Verifikatoren sjekker bytekode på en rekke forskjellige nivåer. Den enkleste testen sørger for at formatet på et byte-kodefragment er riktig. På et mindre grunnleggende nivå blir det brukt en innebygd teoremprover på hvert kodefragment. Teoremprover hjelper til med å sørge for at bytekode ikke forfalsker pekere, bryter tilgangsbegrensninger eller får tilgang til objekter ved hjelp av feil typeinformasjon. Bekreftelsesprosessen, sammen med sikkerhetsfunksjonene innebygd i språket gjennom kompilatoren, hjelper til med å etablere et basissett med sikkerhetsgarantier.
Applet-klasselaster:
Den andre delen av sikkerhetsforsvar er Java Applet Class Loader. Alle Java-objekter tilhører klasser. Applet Class Loader bestemmer når og hvordan en applet kan legge til klasser i et Java-miljø som kjører. En del av jobben er å sørge for at viktige deler av Java-kjøretidsmiljøet ikke blir erstattet av kode som en applet prøver å installere. Generelt kan et Java-miljø som kjører ha mange Class Loaders aktive, som hver definerer sitt eget "navnerom". Navneplasser gjør det mulig å skille Java-klasser i forskjellige "slag" i henhold til hvor de kommer fra. Applet Class Loader, som vanligvis leveres av nettleserleverandøren, laster alle applets og klassene de refererer til. Når en applet lastes over nettverket, mottar Applet Class Loader binære data og instantierer den som en ny klasse.
Sikkerhetssjefen:
Den tredje spissen i Java-sikkerhetsmodellen er Java Security Manager. Denne delen av sikkerhetsmodellen begrenser måtene en applet kan bruke synlige grensesnitt på. Dermed implementerer Security Manager en god del av hele sikkerhetsmodellen. Security Manager er en enkelt modul som kan utføre kjøretidskontroller av "farlige" metoder. Kode i Java-biblioteket konsulterer Security Manager når en farlig operasjon er i ferd med å bli forsøkt. Security Manager får en sjanse til å nedlegge veto mot operasjonen ved å generere et Security Exception (bane av Java-utviklere overalt). Beslutninger tatt av Security Manager tar hensyn til hvilken Class Loader som lastet inn den forespørselsklassen. Innebygde klasser får mer privilegium enn klasser som er lastet over nettet.
Utro og forvist til sandkassen
Sammen utgjør de tre delene av Java-sikkerhetsmodellen sandkassen. Tanken er å begrense hva en applet kan gjøre og sørge for at den spiller etter reglene. Sandkasseideen er tiltalende fordi den er ment å tillate deg å løpe utro koden på maskinen din uten å bekymre deg for den. På den måten kan du surfe på nettet straffri, og kjøre alle Java-appletene du noensinne har kommet over, uten sikkerhetsproblemer. Vel, så lenge Java-sandkassen ikke har noen sikkerhetshull.
Et alternativ til sandkassen:
Autentisering gjennom kodesignering
ActiveX er en annen høyprofilert form for kjørbart innhold. ActiveX er promotert av Microsoft og har blitt kritisert av datasikkerhetsfagfolk som ser på tilnærmingen til sikkerhet som mangler. I motsetning til Java-sikkerhetssituasjonen, hvor en applet er begrenset av programvarekontroll i de slags ting den kan gjøre, har en ActiveX-kontroll ingen begrensninger på oppførselen når den er påkalt. Resultatet er at brukere av ActiveX må være veldig forsiktige med å kjøre bare helt klarert kode. Java-brukere har derimot den luksusen å kjøre upålitelig kode ganske trygt.
ActiveX-tilnærmingen er avhengig av digitale signaturer, en slags krypteringsteknologi der vilkårlige binære filer kan "signeres" av en utvikler eller distributør. Fordi en digital signatur har spesielle matematiske egenskaper, er den ugjenkallelig og uforglemmelig. Det betyr at et program som nettleseren din kan bekrefte en signatur, slik at du kan være sikker på hvem som garanterer koden. (I det minste er det teorien. Ting er litt mer tvetydige i det virkelige liv.) Enda bedre, du kan instruere nettleseren din om alltid å godta kode signert av en part som du stoler på, eller alltid å avvise kode signert av noen parti som du ikke stol på.
En digital signatur inneholder mye informasjon. For eksempel kan den fortelle deg at selv om noe kode distribueres av et nettsted du ikke stoler på, ble det opprinnelig skrevet av noen du stoler på. Eller det kan fortelle deg at selv om koden ble skrevet og distribuert av noen du ikke kjenner, har vennen din signert koden og bekreftet at den er trygg. Eller det kan ganske enkelt fortelle deg hvem av tusenvis av brukere på aol.com skrev koden.
(Se sidefelt for mer informasjon om digitale signaturer, inkludert fem viktige egenskaper.)
Fremtiden for kjørbart innhold: Å forlate sandkassen
Gjør digitale signaturer ActiveX mer attraktivt sikkerhetsmessig enn Java? Vi tror ikke, spesielt i lys av det faktum at digital signatur er nå tilgjengelig i Java's JDK 1.1.1 (sammen med andre sikkerhetsforbedringer). Det betyr at i Java får du alt som ActiveX gjør for sikkerhet i tillegg til muligheten til å kjøre ikke-klarert kode ganske trygt. Java-sikkerhet vil bli forbedret enda lenger i fremtiden med fleksibel, finkornet tilgangskontroll, som ifølge Li Gong, JavaSofts Java-sikkerhetsarkitekt, er planlagt for utgivelse i JDK 1.2. Bedre tilgangskontroll vil også komme seg inn i neste nettleserunde, inkludert Netscape Communicator og MicroSoft Internet Explorer 4.0.
I takt med tilgangskontroll, vil kodesignering tillate at applets går gradvis utenfor sikkerhetssandkassen. For eksempel kan en applet designet for bruk i en intranettinnstilling få lov til å lese og skrive til en bestemt firmadatabase så lenge den ble signert av systemadministratoren. En slik avspenning av sikkerhetsmodellen er viktig for utviklere som tupper for at appletene deres skal gjøre mer. Det er vondt å skrive kode som fungerer innenfor de stramme begrensningene i sandkassen. Den originale sandkassen er veldig restriktiv.
Til slutt vil applets få tillatelse av forskjellige nivåer av tillit. Siden dette krever tilgangskontroll, er nyanser av tillit foreløpig ikke tilgjengelige, selv om kodesignering er det. Slik det for øyeblikket står i JDK 1.1.1, er Java-applets enten helt klarert eller helt klarert. En signert applet merket som klarert har lov til å unnslippe sandkassen. En slik applet kan gjøre hva som helst og har ingen sikkerhetsbegrensninger.
Hovedproblemet med Javas tilnærming til sikkerhet er at det er komplisert. Kompliserte systemer har en tendens til å ha flere feil enn enkle systemer. Sikkerhetsforskere, spesielt Princetons Secure Internet Programming-team, har funnet flere alvorlige sikkerhetsfeil i tidlige versjoner av sandkassen. Mange av disse feilene var implementeringsfeil, men noen var spesifikasjonsfeil. Heldigvis har JavaSoft, Netscape og Microsoft vært veldig raske med å fikse slike problemer når de blir oppdaget. (Tydelige og komplette forklaringer på Java's sikkerhetshull finner du i kapittel 3 i boka vår.)
Bare nylig var markedsførere av Sun (noen ganger kalt evangelister) raske til å påpeke at ingen nye feil hadde blitt oppdaget på ganske lang tid. De tok dette som bevis på at Java aldri igjen ville lide av sikkerhetsproblemer. De hoppet pistolen.
Kodesigneringshullet: Java skinner kneet
Kodesignering er komplisert. Som i den originale sandkassemodellen er det god plass til feil i utformingen og implementeringen av et kodesigneringssystem. Det siste hullet var et ganske greit problem i implementeringen av Java Klasse klasse, som forklart på både Princeton-nettstedet og JavaSofts sikkerhetsside. Nærmere bestemt metoden Class.getsigners () returnerer et mutabelt utvalg av alle signaturer som er kjent for systemet. Det er mulig for en applet å misbruke denne informasjonen. Løsningen var så enkel som å returnere bare en kopi av matrisen, og ikke selve matrisen.
Tenk på en situasjon der en utvikler, Alice, ikke har fått noe sikkerhetsrettighet på en nettbrukeres system. Faktisk, i motsetning til hva den opprinnelige JavaSoft-uttalelsen om feilen hevdet, kan Alice være helt ukjent for systemet. Med andre ord stoler ikke koden signert av Alice mer enn den vanlige appleten utenfor gaten. Hvis nettbrukeren (ved hjelp av HotJava-nettleseren - for øyeblikket det eneste kommersielle produktet som støtter JDK 1.1.1) laster inn en applet signert av Alice, kan den appleten fremdeles gå ut av sandkassen ved å utnytte hullet.
Det faktum at systemet ikke trenger å ha Alice's offentlige nøkkel i databasen, er viktig. Det betyr at Alice kan være hvilken som helst vilkårlig angriper som vet å signere en applet med en helt tilfeldig identitet. Å lage en slik identitet er enkelt, og det samme er å signere en applet med den identiteten. Dette gjør hullet veldig alvorlig.
Hullet gjør at Alices angrepsapplet kan endre systemets ide om hvem som signerte den. Dette er spesielt ille hvis Alice ikke får privilegium å løpe utenfor sandkassen, men Bob gjør det. Alice's applet kan bruke getigners () ring for å endre tillatelsesnivået for å inkludere alle Bobs privilegier. Alice's applet kan få maksimalt antall tilgjengelige rettigheter tildelt hvilken som helst undertegner som systemet kjenner til.
Hvis du sammenligner signatur- / privilegieidentitetene med strøk i et skap, kan Alice's angrepsapplet prøve hver strøk og prøve forskjellige ulovlige ting til den oppdager hvilke av strøkene som er "magiske" og la den få privilegium. Hvis en magisk pels oppdages, kan Alice applet gå ut av sandkassen og gjøre ting den ikke skal få lov til å gjøre. Å prøve på strøk er like enkelt som å prøve en ikke tillatt samtale og se på hva som skjer.
