Trykket i Nettverk & Kommunikasjon nr.6/2000
(c) Anders Fongen 2000
Anders Fongen er høgskolelektor og fagsjef ved Den Polytekniske Høgskolen. Webstedet hans er på www.fongen.no
ILoveYou-viruset er en blanding av en E-post melding og et program. Makrovirus, f.eks. Melissa, er en blanding av dokument og program. Det er mulig å lage virus o.l. på denne måten fordi det forlengst er vanlig å lage dokumenter som inneholder programkode.
På starten av 1990-tallet var undertegnede mye involvert i datasikkerhet i en norsk industribedrift. Den gang var datavirus forurensede programmer, som løsnet og gjorde skade først når programmet ble startet. Viruset ville som regel lete etter andre programmer for å forurense dem på samme måte, og deretter gjøre en eller annen fantestrek.
Slike virus var det ikke så vanskelig å holde i sjakk ved å legge den forutsetning til grunn at programfiler ikke skal endres etter at de er opprettet. Med skrivebeskyttede programområder, som bare en systemadministrator hadde nøkkelen til, ble dette en mulighet (DOS tilbød ikke slik skrivebeskyttelse, men Novell NetWare gjorde det). Ved å innføre dette som et regime (det ble ikke lov å ha programmer på lokal disk eller diskett), sparte denne bedriften seg for mange av de problemene som herjet PC-nettene på den tiden.
Men forutsetningen for en slik beskyttelse er at 1)programfiler endres ikke, og 2)datafiler er "passive" og utfører aldri noen kommander på egen hånd. WordPerfect-dokumenter hadde riktignok en makrofunksjon, men de makroene startet bare på brukers kommando, og hadde ingen mulighet for å lage virus.
Dette holder jo ikke stikk lenger. Forlengst har datafiler fått muligheter for å inneholde makroer som er like så generelle og anvendelige som vanlige programmer, makroer som har mulighet for å endre andre filer, eller starte og styre andre programmer på maskinen. Dessuten er datafilene gitt mulighet for "selvstartende" makroer som utføres når filen åpnes, f.eks. i tekstbehandleren. På denne måten kan et program flyttes fra en maskin til en annen og utføres der, forkledd som et tekstbehandlingsdokument eller et regneark.
Vi ser det samme i E-post systemer: En ankommet melding kan inneholde kode som utføres når meldingen åpnes, gjennom en tjeneste som i Windows kalles "Windows Scripting Host". Denne tjenesten er et slags kjøremiljø for programmer skrevet i VBScript. Her har vi faktisk med det å gjøre som vi kaller for flyttbar kode, og dette er en ny arena for dem som vil sabotere dataverdenen med virus o.l.
Og hvorfor mulighet til å sende kode rundt mellom maskiner og få dem (mer eller mindre) automatisk utført? Fordi dette gir mulighet for enkelt å lage distribuerte applikasjoner. Vanlige klient-tjener anvendelser forutsetter at klienten og tjeneren er blitt enige om hvilke kommandoer og hvilke data som skal utveksles mellom dem. Med flyttbar kode kan partene være hverandres kjøremiljø og de kan utveksle programmer som utføres i f.eks. en "Windows Scripting Host".
Avanserte agentløsninger er laget over en slik plattform. En søkeagent kan være et flyttbart program som kommer til en maskin, søker på lokal disk etter informasjon, og rapporterer funnene tilbake til avsenderen. Agentene kan bruke nye søkemetoder, de kan ta med seg informasjon fra tidligere steder, og de kan legge fra seg informasjon slik at verten også blir klokere av "besøket". Dette er ting som er vanskelig å få til eller upraktisk i en standard klient/tjener konfigurajon.
Andre eksempler er bruk av JavaScript og Java Applets. JavaScript er enkel kildekode som følger med inne i en web-side, og en tolk i web-leseren utfører koden på bestemte hendelser, f.eks. når musen føres over et bestemt sted på bildet, eller når web-siden lastes. JavaScript (evt. VBScript) i en web-side er et dårlig valg for fiendlig kode, fordi det aldri vil kunne skjules hvor koden er hentet fra, og fordi JavaScript aldri får røre miljøet utenfor web-leseren. JavaScript kan bare lage noen irritasjonsmomenter som bare er ris til web-sidens egen bak (man legger vel ut web-sider for at brukerne skal komme dit mer enn én gang?).
Tilsvarende vil det være med Java Applets, som er ferdigkompilert kode som lastes som en del av web-siden, og som utføres av en Java-tolk i web-leseren. Heller ikke en Java Applet har mange muligheter til å gå utenfor web-leseren, men vi skal se at Java har nyansert disse reglene en del i det siste.
Flyttbar kode er på samme tid noe av det beste og verste man kan tenke seg. Samtidig som flyttbar kode representerer nye muligheter i utviklingen av distribuerte applikasjoner, innebærer den også helt nye trusler i form av fiendlige programmer som kommer samme vei som de vennlige. Og det er ikke enkelt å se forskjell på venn og fiende. Samtidig som faremomentene reduseres med regler som ved JavaScript, reduserer den også nytteverdien og fleksibiliteten ved flyttbar kode.
Men vi ønsker bare snille programmer inn i våre maskiner, og hvordan kan vi oppnå det? Er det mulig å skille venn fra fiende? Selvfølgelig ikke. Et program som har lov til å skrive til en fil kan også ødelegge den, og et program med lov til å overføre data i nettverket kan overføre hva som helst over denne forbindelsen.
Det er derimot mulig å bruke et nyansert sett av regler for hva flyttbar kode får lov til å gjøre. JavaScript og Java Applets har (i utgangspunktet) omtrent den samme begrensning som hindrer dem i å bruke det lokale filsystemet, eller å sette opp nettverksforbindelser til annet enn sitt "hjemsted". Dette lar en Applet fungere som en klientapplikasjon i et nettverk, men hindrer en mer fleksibel distribuert applikasjon hvor klientene både snakker til flere andre stasjoner og dessuten blir snakket til selv. Vi ønsker oss derfor at visse egenskaper som programmet har skal avgjøre hva slags rettigheter det skal få.
Rettighetene må reguleres gjennom en database på vertsmaskinen (og intet flyttbart program skal kunne endre disse opplysningene), hvor avsenderen av programmet kan angis med f.eks. en URL (http:/xx.yy.zz/...) hvor bruk av jokertegn kan angi et område i en tjener eller et område i nettet. Java2 benytter en slik metode.
En slik metode baserer seg på en antagelse om at alle programmer fra samme "sted" skal ha de samme rettighetene, noe som ikke nødvendigvis er tilfelle. Et annet problem med metoden er at det kreves kunnskaper om hvilke rettigheter som er nødvendig og tilstrekkelig for at programmet skal kunne gjøre jobben sin. Slik kunnskap er det mange som ikke har, og de har en tendens til å lage for store rettigheter for å være på "den sikre siden".
Dette gir oss det samme problemet ved at man må forstå hvilke rettigheter som skal tildeles, og det krever også at partene har en felles bruk av signaturer som gir den ønskede nøyaktighet (det er ikke sikkert at signaturen "IBM" er nyansert nok).
En viktig fordel med en signatur er at det ikke er mulig for et program å opptre anonymt eller å skjule de personene som er ansvarlig for programmet.
Stillet overfor et problem knyttet til et program som ikke har nok rettigheter til å utføres, vil en bruker normalt tillate hva som helst. Et spørsmål til brukeren om "dette programmet er signert av Suspectronics AS og trenger skriverettigheter til disken din" idet programmet skal utføres vil sjelden gi gjennomtenkte svar. Nei, sikkerhetsspørsmål skal avgjøres på mett mage og i ro og mak.
Men Microsoft har i de fleste sikkerhetsspørsmål gjort det meste galt, og alltid prioritert funksjonalitet fremfor sikkerhet. De har unnlatt bruk av nyanserte rettigheter, og de overlater til brukerne å avgjøre om programmene skal ha tillit eller ikke. Dermed har det skjedd at et VBScript på 274 linjer har gjort så mye skade uten at brukerne har hatt noen sjanse til å unngå det.
Vi håper at hendelsen har satt en støkk i alle dem som stoler på Microsofts sikkerhetsteknologi, og gir dem klar beskjed om å endre sin politikk. Microsofts talsmenn har gitt ganske unnvikende og motvillige svar på de beskyldningene som er blitt satt fram, og vist til at brukerne selv velger sikkerhetsnivået i f.eks. Outlook (som i dette tilfellet var verten for viruset).
Javaprogrammer kan være signert med asymmetrisk krypto, og dermed sørge for at programmets opphavsmann er det som regulerer rettighetene til programmet. Java2 kommer også med verktøy som oppretter nøkkelpar og påfører signatur på programmer (Applets, Jars, Beans m.m.).
De miljøene som vil bruke Javas sikkerhetsteknologi kan dermed (i motsetning til Microsoft) tvinge denne på brukerne, og den største risikoen for fiendtlig angrep er da at den systemansvarlige ikke har gjort jobben sin godt nok.