Du har måske hørt om den seneste fejl i sikkerheden i JDK 1.1 og HotJava 1.0, der for nylig blev opdaget af Secure Internet Programming-teamet ved Princeton University (ledet af en af forfatterne). Hvis du vil have hele historien, skal du læse videre. Men der er mere ved Java-sikkerhed end detaljerne i dette seneste sikkerhedshul. Lad os få noget perspektiv.
Java-sikkerhed og offentlig opfattelse
Alle ved, at sikkerhed er en stor ting for Java. Hver gang der opdages et sikkerhedshul, sprænges historien meget hurtigt ind i computernyhederne (og nogle gange forretningsnyhederne). Du bliver måske ikke overrasket over at høre, at den populære presse overvåger komp. risici og andre sikkerhedsrelaterede nyhedsgrupper. De vælger sikkerhedshistorier for at fremhæve tilsyneladende tilfældigt, men da Java er så varmt i disse dage, udskriver de næsten altid Java-sikkerhedshistorier.
Problemet er, at de fleste nyhedshistorier slet ikke forklarer hullerne godt. Dette kan føre til et klassisk "skrig ulv" -problem, hvor folk bliver vant til at se "denne uges sikkerhedshistorie" og ikke uddanner sig om de meget reelle risici ved eksekverbart indhold. Desuden har leverandører en tendens til at bagatellisere deres sikkerhedsproblemer og dermed forvirre nøgleproblemerne yderligere.
Den gode nyhed er, at JavaSoft-sikkerhedsteamet seriøst med at gøre Java sikker. Den dårlige nyhed er, at et flertal af Java-udviklere og brugere måske tror på den hype, der stammer fra begivenheder som JavaOne, hvor sikkerhedsproblemer ikke får meget airplay. Som vi sagde i vores bog, Java-sikkerhed: Fjendtlige applets, huller og modgift, Sun Microsystems har meget at vinde, hvis det får dig til at tro, at Java er helt sikkert. Det er rigtigt, at leverandørerne har gjort meget for at gøre deres Java-implementeringer så sikre som muligt, men udviklere ønsker ikke indsats; de vil have resultater.
Da en Java-aktiveret webbrowser tillader, at Java-kode integreres i en webside, downloades over nettet og køres på en lokal maskine, er sikkerhed et kritisk problem. Brugere kan downloade Java-applets med enestående lethed - nogle gange uden selv at vide det. Dette udsætter Java-brugere for en betydelig risiko.
Java's designere er meget opmærksomme på de mange risici, der er forbundet med eksekverbart indhold. For at bekæmpe disse risici designede de Java specifikt med sikkerhedsproblemer i tankerne. Hovedmålet var at tackle sikkerhedsspørgsmålet head-on, så naive brugere (for eksempel et flertal af de millioner af websurfere) ikke behøver at blive sikkerhedseksperter bare for sikkert at gennemse Internettet. Dette er et beundringsværdigt mål.
De tre dele af Java-sandkassen
Java er et meget stærkt udviklingssprog. Ikke-tillid til applets bør ikke få adgang til al denne magt. Java-sandkassen begrænser applets fra at udføre mange aktiviteter. Det bedste tekniske papir om appletbegrænsninger er "Low Level Security in Java" af Frank Yellin.
Java-sikkerhed er afhængig af tre forsvarspunkter: Byte Code Verifier, Class Loader og Security Manager. Tilsammen udfører disse tre stifter load- og run-time-kontrol for at begrænse filsystem- og netværksadgang samt adgang til browserinterne. Hver af disse stifter afhænger på en eller anden måde af de andre. For at sikkerhedsmodellen skal fungere korrekt, skal hver del udføre sit arbejde korrekt.
Byte-kode-verifikator:
Byte Code Verifier er den første stift i Java-sikkerhedsmodellen. Når et Java-kildeprogram er kompileret, kompileres det ned til platformuafhængig Java-byte-kode. Java-byte-kode er "verificeret", før den kan køre. Denne verifikationsplan er beregnet til at sikre, at bytekoden, som måske eller måske ikke er oprettet af en Java-kompilator, spiller efter reglerne. Når alt kommer til alt, kunne bytekode godt være skabt af en "fjendtlig kompilator", der samlede bytekode designet til at nedbryde den virtuelle Java-maskine. Bekræftelse af en applets bytekode er en måde, hvorpå Java automatisk kontrollerer utroværdig ekstern kode inden det får lov til at køre. Verifikatoren kontrollerer bytekode på et antal forskellige niveauer. Den enkleste test sørger for, at formatet på et byte-kodefragment er korrekt. På et mindre grundlæggende niveau anvendes en indbygget sætningsprover på hvert kodefragment. Teoremprover hjælper med at sikre, at bytekode ikke skaber markører, overtræder adgangsbegrænsninger eller får adgang til objekter ved hjælp af forkerte typeoplysninger. Verifikationsprocessen, sammen med de sikkerhedsfunktioner, der er indbygget i sproget gennem compileren, hjælper med at etablere et basissæt af sikkerhedsgarantier.
Applet-klasselæsseren:
Den anden del af sikkerhedsforsvar er Java Applet Class Loader. Alle Java-objekter hører til klasser. Applet Class Loader bestemmer, hvornår og hvordan en applet kan føje klasser til et kørende Java-miljø. En del af opgaven er at sikre, at vigtige dele af Java-runtime-miljøet ikke erstattes af kode, som en applet forsøger at installere. Generelt kan et kørende Java-miljø have mange Class Loaders aktive, der hver definerer sit eget "navneområde". Navneområder tillader, at Java-klasser adskilles i forskellige "slags" alt efter hvor de kommer fra. Applet Class Loader, der typisk leveres af browserudbyderen, indlæser alle applets og de klasser, de refererer til. Når en applet indlæses på tværs af netværket, modtager Applet Class Loader binære data og instantierer dem som en ny klasse.
Sikkerhedschefen:
Den tredje spids i Java-sikkerhedsmodellen er Java Security Manager. Denne del af sikkerhedsmodellen begrænser de måder, hvorpå en applet kan bruge synlige grænseflader. Således implementerer Security Manager en god del af hele sikkerhedsmodellen. Security Manager er et enkelt modul, der kan udføre kørselstid på "farlige" metoder. Kode i Java-biblioteket konsulterer Security Manager, hver gang en farlig handling er ved at blive forsøgt. Security Manager får en chance for at nedlægge veto mod operationen ved at generere en sikkerhedsundtagelse (bane fra Java-udviklere overalt). Afgørelser truffet af Security Manager tager højde for, hvilken Class Loader, der indlæste den anmodende klasse. Indbyggede klasser får mere privilegium end klasser, der er indlæst over nettet.
Utro og forvist til sandkassen
Sammen udgør de tre dele af Java-sikkerhedsmodellen sandkassen. Ideen er at begrænse, hvad en applet kan gøre, og sørge for, at den spiller efter reglerne. Sandkasseideen er tiltalende, fordi den er beregnet til at give dig mulighed for at løbe utro kode på din maskine uden at bekymre dig om det. På den måde kan du surfe på nettet med straffrihed og køre hver Java-applet, du nogensinde er stødt på, uden sikkerhedsproblemer. Nå, så længe Java-sandkassen ikke har nogen sikkerhedshuller.
Et alternativ til sandkassen:
Godkendelse gennem kodesignering
ActiveX er en anden højt profileret form af eksekverbart indhold. ActiveX er blevet fremmet af Microsoft og er blevet kritiseret af professionelle inden for computersikkerhed, der ser dens tilgang til sikkerhed mangler. I modsætning til Java-sikkerhedssituationen, hvor en applet er begrænset af softwarekontrol i de slags ting, den kan gøre, har en ActiveX-kontrol ingen begrænsninger for dens adfærd, når den først påberåbes. Resultatet er, at brugere af ActiveX kun skal være meget forsigtige med at køre fuldstændig pålidelig kode. Java-brugere har derimod den luksus at køre utroskabskode temmelig sikkert.
ActiveX-metoden er afhængig af digitale signaturer, en slags krypteringsteknologi, hvor vilkårlige binære filer kan "underskrives" af en udvikler eller distributør. Fordi en digital signatur har specielle matematiske egenskaber, er den uigenkaldelig og uforglemmelig. Det betyder, at et program som din browser kan bekræfte en signatur, så du kan være sikker på, hvem der garanterede koden. (I det mindste er det teorien. Tingene er lidt mere tvetydige i det virkelige liv.) Endnu bedre, du kan bede din browser altid om at acceptere kode underskrevet af en part, som du stoler på, eller altid at afvise kode underskrevet af en part, som du stol ikke på.
En digital signatur indeholder masser af information. For eksempel kan det fortælle dig, at selvom en kode omdistribueres af et websted, du ikke stoler på, blev det oprindeligt skrevet af en, du har tillid til. Eller det kan fortælle dig, at selvom koden blev skrevet og distribueret af nogen, du ikke kender, har din ven underskrevet koden og bekræfter, at den er sikker. Eller det fortæller dig simpelthen, hvem af de tusinder af brugere der er aol.com skrev koden.
(Se sidebjælke for flere detaljer om digitale signaturer, herunder fem nøgleegenskaber.)
Fremtiden for eksekverbart indhold: Forlader sandkassen
Gør digitale signaturer ActiveX mere attraktivt sikkerhedsmæssigt end Java? Vi tror ikke, især i lyset af det faktum, at digital signaturfunktion nu er tilgængelig i Java's JDK 1.1.1 (sammen med andre sikkerhedsforbedringer). Det betyder i Java, at du får alt, hvad ActiveX gør for sikkerhed plus evnen til at køre utroværdig kode temmelig sikkert. Java-sikkerhed forbedres endnu længere i fremtiden ved hjælp af fleksibel, finkornet adgangskontrol, som ifølge Li Gong, JavaSofts Java-sikkerhedsarkitekt, er planlagt til frigivelse i JDK 1.2. Bedre adgangskontrol vil også komme ind i den næste runde af browsere, herunder Netscape Communicator og MicroSoft Internet Explorer 4.0.
I takt med adgangskontrol vil kodesignering tillade, at applets trinvis går ud af sikkerhedssandkassen. For eksempel kan en applet designet til brug i en intranetindstilling få lov til at læse og skrive til en særlig firmadatabase, så længe den blev underskrevet af systemadministratoren. En sådan lempelse af sikkerhedsmodellen er vigtig for udviklere, der chopper for at deres applets skal gøre mere. At skrive kode, der fungerer inden for de stramme begrænsninger i sandkassen, er en smerte. Den originale sandkasse er meget restriktiv.
Til sidst får applets forskellige niveauer af tillid. Da dette kræver adgangskontrol, er nuancer af tillid i øjeblikket ikke tilgængelige, selvom kodesignering er. Som det i øjeblikket står i JDK 1.1.1, er Java-applets enten fuldstændig tillid til eller helt ikke tillid til. En underskrevet applet, der er markeret som betroet, har lov til at undslippe sandkassen helt. En sådan applet kan overhovedet gøre alt og har ingen sikkerhedsrestriktioner.
Hovedproblemet med Java's tilgang til sikkerhed er, at det er kompliceret. Komplicerede systemer har tendens til at have flere mangler end enkle systemer. Sikkerhedsforskere, især Princetons Secure Internet Programming team, har fundet flere alvorlige sikkerhedsfejl i tidlige versioner af sandkassen. Mange af disse fejl var implementeringsfejl, men nogle var specifikationsfejl. Heldigvis har JavaSoft, Netscape og Microsoft været meget hurtige til at løse sådanne problemer, når de bliver opdaget. (Tydelige og komplette forklaringer på Java's sikkerhedshuller findes i kapitel 3 i vores bog.)
For nylig var solmarkedsførere (undertiden kaldet evangelister) hurtige til at påpege, at der ikke var opdaget nye mangler i nogen tid. De tog dette som bevis for, at Java aldrig igen ville lide af sikkerhedsproblemer. De sprang pistolen.
Kodesigneringshullet: Java skinner sit knæ
Kodesignering er kompliceret. Som i den originale sandkassemodel er der masser af plads til fejl i design og implementering af et kodesigneringssystem. Det nylige hul var et ret ligetil problem i implementeringen af Java'er Klasse
klasse, som forklaret på både Princeton-webstedet og JavaSofts sikkerhedswebsted. Specifikt metoden Class.getsigners ()
returnerer et ændret array med alle underskrivere, som systemet kender. Det er muligt for en applet at misbruge disse oplysninger. Fixet var så simpelt som at returnere kun en kopi af arrayet og ikke selve arrayet.
Overvej en situation, hvor en udvikler, Alice, ikke har fået nogen sikkerhedsrettigheder på en webbrugeres system. Faktisk i modsætning til hvad den oprindelige JavaSoft-erklæring om fejlen hævdede, kan Alice være helt ukendt for systemet. Med andre ord er kode underskrevet af Alice ikke mere betroet end den sædvanlige applet fra gaden. Hvis webbrugeren (ved hjælp af HotJava-browseren - i øjeblikket det eneste kommercielle produkt, der understøtter JDK 1.1.1) indlæser en applet underskrevet af Alice, kan den applet stadig træde ud af sandkassen ved at udnytte hullet.
Det er vigtigt, at systemet ikke behøver Alice's offentlige nøgle i sin database. Det betyder, at Alice kan være enhver vilkårlig angriber, der ved, hvordan man underskriver en applet med en helt tilfældig identitet. Det er nemt at oprette en sådan identitet, ligesom det er at underskrive en applet med denne identitet. Dette gør hullet meget alvorligt.
Hullet gør det muligt for Alices angrebsapplet at ændre systemets idé om, hvem der har underskrevet den. Dette er især dårligt, hvis Alice ikke får privilegium til at løbe uden for sandkassen, men det er Bob. Alice's applet kan bruge getigners ()
kald for at ændre niveauet for tilladelse til at medtage alle Bobs privilegier. Alice's applet kan få det maksimale antal tilgængelige privilegier tildelt enhver underskriver, der er kendt af systemet.
Hvis du sammenligner signatur- / privilegieidentiteterne med frakker i et skab, kan Alice's angrebsapplet prøve hver pels og forsøge forskellige ting, der ikke er tilladt, indtil den opdager, hvilken af frakkerne der er "magiske" og lade den få privilegium. Hvis der opdages en magisk frakke, kan Alice's applet træde ud af sandkassen og gøre ting, som den ikke burde have lov til at gøre. At prøve frakker er så simpelt som at prøve et ikke-tilladt opkald og se på, hvad der sker.