Programiranje

Razumevanje ključev varnosti Java - peskovnika in preverjanja pristnosti

Morda ste že slišali za zadnjo napako v varnosti JDK 1.1 in HotJava 1.0, ki jo je pred kratkim odkrila ekipa za varno internetno programiranje na univerzi Princeton (pod vodstvom enega od avtorjev). Če želite celotno zgodbo, berite naprej. Toda varnost Java še ni več kot podrobnosti o tej najnovejši varnostni luknji. Poglejmo si nekaj perspektive.

Varnost Java in zaznavanje javnosti

Vsi vemo, da je varnost za Javo velik zalogaj. Kadar koli se odkrije varnostna luknja, zgodba zelo hitro vdre v računalniške novice (in včasih tudi v poslovne novice). Morda vas ne bo presenetilo, ko boste izvedeli, da priljubljeni tisk spremlja comp.risks in druge novice, povezane z varnostjo. Izbirajo varnostne zgodbe, da bi na videz naključno poudarili, čeprav ker je Java danes tako vroča, skoraj vedno natisnejo varnostne zgodbe Java.

Težava je v tem, da večina novic sploh ne razloži lukenj dobro. To bi lahko privedlo do klasičnega problema "jokajočega volka", kjer se ljudje navadijo videti "varnostno zgodbo tega tedna" in se ne poučujejo o zelo resničnih tveganjih izvedljivih vsebin. Poleg tega prodajalci ponavadi zmanjšajo svoje varnostne težave in tako še bolj zmedejo ključna vprašanja.

Dobra novica je, da se ekipa JavaSoft za varnost resno ukvarja z zagotavljanjem varnosti Java. Slaba novica je, da lahko večina razvijalcev in uporabnikov Java verjame v hrup, ki izvira iz dogodkov, kot je JavaOne, kjer varnostne težave nimajo velikega vpliva. Kot smo rekli v naši knjigi, Java Security: sovražni programčki, luknje in protistrupi, Sun Microsystems lahko veliko pridobi, če prepričate, da je Java popolnoma varna. Res je, da so se prodajalci zelo potrudili, da so njihove izvedbe Java čim bolj varne, vendar razvijalci ne želijo truda; hočejo rezultate.

Ker spletni brskalnik, ki podpira Java, omogoča, da se kodo Java vdela v spletno stran, jo prenese po omrežju in zažene na lokalnem računalniku, je varnost ključnega pomena. Uporabniki lahko javanske programčke naložijo z izjemno lahkoto - včasih, ne da bi sploh vedeli. To izpostavlja uporabnike Jave velikemu tveganju.

Oblikovalci Jave se dobro zavedajo številnih tveganj, povezanih z izvedljivo vsebino. Za boj proti tem tveganjem so Javo zasnovali posebej z upoštevanjem varnostnih vprašanj. Glavni cilj je bil, da se varnostnega vprašanja loti čelno, tako da naivnim uporabnikom (recimo večini milijonov spletnih deskarjev) ne bi bilo treba postati varnostni strokovnjaki samo zato, da bi varno brskali po spletu. To je občudovanja vreden cilj.

Trije deli peskovnika Java

Java je zelo močan razvojni jezik. Nezaupljivi programčki ne smejo imeti dostopa do vse te moči. Peskovnik Java omejuje programčke pri izvajanju številnih dejavnosti. Najboljši tehnični članek o omejitvah programčkov je "Nizka raven varnosti v Javi" Franka Yellina.

Zaščita Java temelji na treh zaščitnih sklopih: preveritelju bajtnih kod, naložitelju razredov in upravitelju varnosti. Ti trije zobniki skupaj izvajajo preverjanja obremenitve in časa izvajanja, da omejijo dostop do datotečnega sistema in omrežja ter dostop do notranjih delov brskalnika. Vsak od teh rogljev je na nek način odvisen od ostalih. Da bo varnostni model pravilno deloval, mora vsak del pravilno opravljati svoje delo.

Preverjevalnik bajtne kode:

Preverjevalnik bajtnih kod je prvi zobnik varnostnega modela Java. Ko je izvorni program Java preveden, se prevede v neodvisno od platforme bajtno kodo Java. Bajtna koda Java je "preverjena", preden se lahko zažene. Ta verifikacijska shema naj bi zagotovila, da se bajtna koda, ki jo je morda ustvaril prevajalnik Java, predvaja po pravilih. Navsezadnje bi bajtno kodo lahko ustvaril "sovražni prevajalnik", ki je sestavil bajtno kodo, zasnovano tako, da sesuje navidezni stroj Java. Preverjanje bajtne kode programčka je en način, na katerega Java samodejno preveri nezaupljivo zunanjo kodo preden je dovoljeno teči. Preverjevalnik preverja bajtno kodo na več različnih ravneh. Najenostavnejši test poskrbi, da je oblika fragmenta bajt-kode pravilna. Na manj osnovni ravni se za vsak fragment kode uporablja vgrajeni preizkuševalec izrekov. Preverjevalnik izrekov pomaga zagotoviti, da bajtna koda ne ponareja kazalcev, krši omejitev dostopa ali dostopa do predmetov z napačnimi informacijami o tipu. Postopek preverjanja skupaj z varnostnimi funkcijami, vgrajenimi v jezik prek prevajalnika, pomaga vzpostaviti osnovni nabor varnostnih jamstev.

Nalagalnik razreda apletov:

Drugi nosilec varnostne obrambe je Java Applet Class Loader. Vsi predmeti Java spadajo v razrede. Nalagalnik razredov programčkov določa, kdaj in kako lahko programček doda razrede v delujoče okolje Java. Del njegove naloge je zagotoviti, da pomembni deli okolja Java med izvajanjem ne bodo nadomeščeni s kodo, ki jo skuša namestiti programček. Na splošno lahko v delujočem okolju Java deluje veliko nalagalnikov razredov, od katerih vsak definira svoj "imenski prostor". Imenski prostori omogočajo, da se razredi Java razdelijo v različne "vrste" glede na to, od kod izvirajo. Nalagalnik razredov aplikacij, ki ga običajno dobavi prodajalec brskalnika, naloži vse programčke in razrede, na katere se sklicujejo. Ko se programček naloži po omrežju, program za nalaganje razredov programčkov prejme binarne podatke in jih ustvari kot nov razred.

Vodja varnosti:

Tretji del varnostnega modela Java je Java Security Manager. Ta del varnostnega modela omejuje načine, na katere lahko programček uporablja vidne vmesnike. Tako Security Manager izvaja dober del celotnega varnostnega modela. Security Manager je en sam modul, ki lahko izvaja preverjanja med izvajanjem "nevarnih" metod. Koda v knjižnici Java se obrne na varnostnega upravitelja, kadar koli se poskuša nevarna operacija. Varnostnemu upravitelju se omogoči veto na operacijo z ustvarjanjem varnostne izjeme (povsod, kjer so razvijalci Java). Pri odločitvah varnostnega upravitelja se upošteva, kateri nalagalnik razredov je naložil zahtevani razred. Vgrajeni razredi imajo več privilegij kot razredi, ki so bili naloženi prek mreže.

Zaupanja vreden in pregnan v peskovnik

Trije deli varnostnega modela Java skupaj sestavljajo peskovnik. Ideja je omejiti delovanje programa in zagotoviti, da se igra po pravilih. Ideja peskovnika je privlačna, ker naj bi vam omogočila tek nezaupljiv kodo na vašem računalniku, ne da bi vas skrbelo. Tako lahko nekaznovano brskate po spletu in brez varnostnih težav zaženete vsak programček Java, na katerega ste kdaj naleteli. No, dokler peskovnik Java nima varnostnih lukenj.

Alternativa peskovniku:

Preverjanje pristnosti s podpisovanjem kode

ActiveX je še ena odmevna oblika izvršljive vsebine. Microsoft, ki ga promovira Microsoft, so kritizirali strokovnjaki za računalniško varnost, ki menijo, da njegov pristop k varnosti ni dovolj. V nasprotju z varnostno situacijo v Javi, pri kateri je programček omejen s programskim nadzorom pri vseh vrstah stvari, ki jih lahko naredi, kontrolnik ActiveX nima omejitev v svojem vedenju, ko je poklican. Rezultat tega je, da morajo biti uporabniki ActiveX-a zelo previdni, da zaženejo samo popolnoma zaupanja vredna koda. Uporabniki Jave pa imajo razkošje, da nezaupljivo kodo izvajajo dokaj varno.

Pristop ActiveX se opira na digitalne podpise, nekakšno tehnologijo šifriranja, pri kateri lahko razvijalec ali distributer "podpiše" poljubne binarne datoteke. Ker ima digitalni podpis posebne matematične lastnosti, je nepreklicen in nepozaben. To pomeni, da lahko program, kot je vaš brskalnik, preveri podpis, kar vam omogoča, da ste prepričani, kdo je jamčil za kodo. (Vsaj to je teorija. V resničnem življenju so stvari nekoliko dvoumnejše.) Še bolje, brskalniku lahko naročite, naj vedno sprejema kodo, ki jo podpiše katera stranka, ki ji zaupate, ali pa vedno zavrne kodo, ki jo je podpisala neka stranka, ki jo ne zaupajte.

Digitalni podpis vsebuje veliko informacij. Lahko vam na primer pove, da čeprav neko spletno mesto, ki mu ne zaupate, ponovno distribuira neko kodo, jo je prvotno napisal nekdo, ki mu zaupate. Lahko pa vam pove, da čeprav je kodo napisal in razdelil nekdo, ki ga ne poznate, je vaš prijatelj kodo podpisal in potrdil, da je varna. Lahko pa vam preprosto pove, kateri od tisočih uporabnikov je aol.com napisal kodo.

(Za več podrobnosti o digitalnih podpisih, vključno s petimi ključnimi lastnostmi, glejte stransko vrstico.)

Prihodnost izvršljive vsebine: Zapuščanje peskovnika

Ali digitalni podpisi naredijo ActiveX bolj privlačen glede varnosti kot Java? Prepričani smo, da ne, zlasti glede na dejstvo, da je zdaj v Javinem JDK 1.1.1 (skupaj z drugimi izboljšavami varnosti) na voljo možnost digitalnega podpisa. To pomeni, da v Javi dobite vse, kar ActiveX počne zaradi varnosti plus zmožnost dokaj varnega zagona nezaupljive kode. Zaščito Java bomo v prihodnosti še izboljšali s prilagodljivim, drobnozrnatim nadzorom dostopa, ki naj bi bil po besedah ​​Li Gonga, JavaSoft-ovega varnostnega arhitekta JavaSoft, izdan v JDK 1.2. Boljši nadzor dostopa se bo uvrstil tudi v naslednji krog brskalnikov, vključno z Netscape Communicator in MicroSoft Internet Explorer 4.0.

V povezavi z nadzorom dostopa bo podpisovanje kode omogočilo, da bodo apleti postopoma stopili izven varnostnega peskovnika. Na primer, programčku, ki je zasnovan za uporabo v nastavitvah intraneta, je dovoljeno branje in pisanje v posebno zbirko podatkov podjetja, če jo je podpisal skrbnik sistema. Takšna sprostitev varnostnega modela je pomembna za razvijalce, ki se trudijo, da bi njihovi apleti naredili več. Pisanje kode, ki deluje v tesnih omejitvah peskovnika, je muka. Prvotni peskovnik je zelo omejujoč.

Sčasoma bo programčkom omogočeno različno zaupanje. Ker to zahteva nadzor dostopa, odtenki zaupanja trenutno niso na voljo, čeprav je podpisovanje kode. Kot trenutno velja v JDK 1.1.1, so Java-apleti popolnoma zaupanja vredni ali popolnoma nezaupljivi. Podpisani programček, označen kot zaupanja vreden, lahko popolnoma uide iz peskovnika. Takšen programček lahko sploh naredi in ima brez varnostnih omejitev.

Glavna težava Javinega pristopa k varnosti je ta, da je zapleten. Zapleteni sistemi imajo običajno več napak kot preprosti sistemi. Varnostni raziskovalci, predvsem Princetonova skupina za varno internetno programiranje, so v zgodnjih različicah peskovnika našli več resnih varnostnih napak. Mnoge od teh napak so bile napake pri izvedbi, nekatere pa napake pri specifikaciji. Na srečo so JavaSoft, Netscape in Microsoft zelo hitro odpravili takšne težave, ko jih odkrijejo. (Jasne in popolne razlage varnostnih lukenj Java najdete v 3. poglavju naše knjige.)

Pred kratkim so tržniki družbe Sun (včasih imenovani tudi evangelisti) hitro opozorili, da v kar nekaj časa niso odkrili novih napak. To so jemali kot dokaz, da Java nikoli več ne bo trpela zaradi varnostnih težav. Skočili so iz pištole.

Luknja za podpisovanje kode: Java si odtrga koleno

Podpisovanje kode je zapleteno. Kot pri prvotnem modelu peskovnika je tudi pri načrtovanju in izvedbi sistema za podpisovanje kod dovolj prostora za napake. Nedavna luknja je bila dokaj neposredna težava pri izvajanju Jave Razred razred, kot je razloženo na spletnem mestu Princeton in JavaSoft. Natančneje, metoda Class.getsigners () vrne spremenljivo polje vseh podpisnikov, ki jih sistem pozna. Applet lahko te podatke zlorabi. Popravek je bil tako preprost kot vrnitev samo kopije matrike in ne same matrike.

Razmislite o situaciji, v kateri razvijalka Alice ni dobila nobenega varnostnega privilegija v sistemu spletnega uporabnika. Dejansko je Alice lahko v nasprotju s prvotno izjavo JavaSoft o hrošču popolnoma neznana sistemu. Z drugimi besedami, kodi, ki jo je podpisala Alice, ne zaupajo nič več kot običajnemu apletu z ulice. Če spletni uporabnik (z uporabo brskalnika HotJava - trenutno edini komercialni izdelek, ki podpira JDK 1.1.1) naloži programček, ki ga je podpisala Alice, lahko ta programček izkoristi luknjo v peskovniku.

Pomembno je dejstvo, da sistemu v bazi podatkov ni treba imeti Aliceinega javnega ključa. To pomeni, da je Alice lahko poljuben napadalec, ki zna podpisati aplet s popolnoma naključno identiteto. Ustvarjanje takšne identitete je enostavno, tako kot podpisovanje apleta s to identiteto. Zaradi tega je luknja res zelo resna.

Luknja omogoča, da napadalni program Alice spremeni sistemsko predstavo o tem, kdo ga je podpisal. To je še posebej slabo, če Alice ne podeli privilegija za tek zunaj peskovnika, Bob pa jo. Alicein aplet lahko uporablja pridobivalci () pokličite, da spremenite raven dovoljenja, da bo vključeval vse Bobove privilegije. Alicein programček lahko dobi največje število razpoložljivih privilegijev kateri koli podpisnik, ki ga sistem pozna.

Če identitete podpisov / privilegij primerjate s plašči v omari, lahko Alice-in aplet za napad poskusi vsak plašč in poskusi različne nedovoljene stvari, dokler ne odkrije, kateri plašči so "čarobni" in mu omogoči, da pridobi privilegij. Če odkrijejo čarobni plašč, lahko Alicein aplet stopi iz peskovnika in počne stvari, ki jih ne bi smel. Preizkušanje plaščev je tako preprosto kot poskus nedovoljenega klica in gledanje, kaj se zgodi.

$config[zx-auto] not found$config[zx-overlay] not found