NYT blev Neumann'ed

Der er en god artikel i New York Times idag, om ingen ringere end Peter G. Neumann, kendt som PGN og redaktør på RISKS digests.

Det handler om et projekt som PGN og min gode ven og lusepuster Robert Watson er igang med, der handler om at starte sikkerhedsimplementeringen fra hardware niveau.

ACM Queue har et interessant video-interview med Rwatson om projektet lige nu.

Rwatson har også et blogindlæg på Cambridge gruppens blog, med lidt flere detaljer og links.

Med lidt held, vil vi kigge tilbage på dette projekt som der hvor vi begyndet at få rigtig computersikkerhed, frem of snakeoil, antivirus og malware-scanninger der bare gør ting værre.

Følg med fra starten...

phk

Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jacob Christian Munch-Andersen

Sjovt, jeg ville mene at den simple, og åbenlyst overlegne løsning ligger i den stik modsatte retning. Implementer en sikker virtuel maskine med software multitasking osv. og kør alt andet igennem den, så behøver CPUen ikke at have specielle sikkerhedsfeatures.

Det næststørste problem ved sikkerhedsfeatures i hardwaren er at de er rene runtime features, alle de smarte ting som man kan gøre under kompileringen er lukket land.

Det største problem er at hardware features ikke kan opdateres, lige så snart man har valgt en model og sat den i produktion er man låst fast. Nye features bliver lidt af en klippe-klistre affære, og det tager genre flere generationer at få dem taget i anvendelse. Det er så godt som umuligt at fjerne gamle features, og hele molevitten bliver ved med at koste transistorer.

Det er selvfølgelig en hård opgave at skrive sådan en virtuel maskine så den både er hurtig og fejlfri, men jeg kan ikke se at det skulle blive lettere af at man flytter opgaven til hardware, jo mere komplekse opgaver man lægger i hardwarelaget jo større bliver risikoen for hardwarefejl.

En lidt mere jordnær fordel ved et software sikkerhedslag frem for et tilsvarende hardware lag er at det kan køres oven på vore nuværende arkitektur, enten som en virtuel maskine oven på et eksisterende OS (hvor sikkerhedsmæssige gevinster dog vil være begrænsede så længe der også anvendes software som kører uden for denne VM), eller som et OS der blot ikke benytter de eksisterende sikkerhedsfeatures i x86.

  • 4
  • 0
Poul-Henning Kamp Blogger

Det næststørste problem ved sikkerhedsfeatures i hardwaren er at de er rene runtime features, alle de smarte ting som man kan gøre under kompileringen er lukket land.

Det er simpelthen ikke rigtigt, men du er lovligt undskyldt.

Der var en gang man rodede med at lade CPU'er lave mere end "bare flytte bits" og der er mange berømte maskiner i tidens løb som har været på den galej.

Cambridges egen CAP maskine er en af disse unika, men der er mange andre af relevans, herunder Linn's "Rekursiv" computer, GE-645 computeren under Multics og for den sags skyld Nationals 532 og Intels Ia432 chips.

Alle disse forsøg og experimenter, pår er faldet til side, fordi den slags "ekstra arbejde" koster performance.

Undtagelsen er Rational R1000 der havde god kommerciel success i det eneste miljø hvor man tog sikkerhed så alvorligt som de fleste af os nu er nødt til: MIL-Spec software udvikling. (jeg er ved at starte en R1000 i datamuseum.dk :-)

Hvis man laver en egentlig "objektorienteret" computer, med hardware håndtering (som f.eks Rekursiv) og samtidig gør det til hardwarens job at styre "capabilities" (som CAP og lidt R1000) opnår man en platform hvor også operativsystemets kode bliver resistent overfor "out of the envelope" angreb (stack/buffer overflow) men også information-leak/tampering angreb (spy-ware etc.)

På sin vis er det et forsøg på at få skovlen under Kernighans forbandelse ("trusting trust") og der er ingen måde software kan gøre det alene. Hardware har en bedre chance.

  • 3
  • 1
Jacob Gorm Hansen

Er der er gammel artikel (https://cseweb.ucsd.edu/~savage/papers/HotOS95.pdf) der hedder.

Jeg synes Dr Watson springer let hen over de senere aars mange lovende teknikker saasom SFI, CFI, XFI, Google Native Client og Rocksalt, Microsoft's Singularity mv., som ogsaa ville kunne loese de problemer han remser op. Det er ret typisk at kerne-hakkere absolut vil have at alting skal loeses i en kerne, om saa hardwaren maa bygges om. Jeg var selv tidligere af samme opfattelse som Watson, men efter at have arbejdet paa Microsoft Research's XFI-projekt, og selv at have implementeret en XFI-prototype med LLVM, er jeg overbevist om at den slags er vejen frem.

  • 0
  • 0
Poul-Henning Kamp Blogger

Problemet med software-only løsninger er at der skal bare et lille hul til, så ramler hele korthuset.

Java er det bedste eksempel på dette problem: En software-only løsning der "bare" skulle implementere en sikker sandkasse og livet har været et helvede at patches lige siden.

Et af de mest imponerende angreb jeg selv har haft fingre i, blev hele operativsystemet "løftet op" i en virtuel software maskine, som angriberens kode implementerede og derfor var angrebet totalt usynligt set fra indersiden, for der var slet ikke noget angreb på det abstrationsniveau.

Det er ikke et hul som Capabilities-i-hw lukker definitivt, men det flytter sværhedsgraden rigtig mange hak op ad stolpen, samtidig med at det giver mulighed for at bryde "God, Root, what difference?" design-fejlen ned til noget meget mere håndterbart.

Der er ingen enkle eller smukke løsninger på sikkerhedsproblemet, men hvis man kan reducere footprint for den kritiske capability-management kode fra at være en hel kerne på flere millioner kodelinier, skrevet af snart sagt hvem som helst, til at være en "mikrokerne" der kan kontrolleres strengt og som kan partitionere også kernens kode, så er meget vundet.

  • 1
  • 0
Leonard Kramer

Jeg er ikke decideret imod at sikkerheden bliver implementeret ned til hardware niveau. Hvad jeg er lidt bange for er at producenter vil bruge det som et påskud til at indbygge DRM og forhindre alternative styre systemer i at blive kørt, lidt ligesom debatten i øjeblikket med UEFI.

Det behøver absolut ikke at blive sådan, men jeg ser bare ikke særlig mange altruiske/ideologiske HW/SW producenter derude som er store nok til at gennemtrumfe åbent hardware, udover muligvis Google (hvis motiver sommetider kan virker lidt... uforudselige).

  • 1
  • 0
Torben Mogensen Blogger

Java er det bedste eksempel på dette problem: En software-only løsning der "bare" skulle implementere en sikker sandkasse og livet har været et helvede at patches lige siden.

Problemet med Java er, at man hældte en masse nye features og optimeringer i den virtuelle maskine, og hver gang fulgte der nye sikkerhedshuller med. Hvis man havde holdt den virtuelle maskine enkel nok, var det ikke sket.

Sikkerhed er i bund og grund et spørgsmål om kontrakter: Man opstiller sikkerhedskravene i en kontrakt, og hvis alle dele af systemet opfylder deres kontrakter, er systemet sikkert. Hvis blot en enkel del ikke gør det, er systemet ikke sikkert. Og det er uanset om denne del er lavet i hardware eller i software.

Det er muligt at sammensætte komponenter med kontrakter på en sådan måde, at hvis de enkelte komponenter opfylder deres delkontrakter, så det samlede system opfylde en kombineret kontrakt.

Denne øvelse kan laves både i hardware og i software, og der er i princippet ikke nogen forskel. Et computersystem skal dog nødvendigvis indeholde noget hardware, så ingen løsning kan være software-only. Men man kan klare sig med meget enkle kontrakter til hardwaren. For eksempel, at udvalgte instruktioner gør som specificeret og, at ting, man skriver til lageret, ikke ændres, inden det læses tilbage igen. Denne simple kontrakt til hardwaren kræver så mere komplicerede kontrakter mellem softwarekomponenter, for eksempel at de ikke rører ved hinandens lager eller kode. Men hvis disse kontrakter er verificerede, er det ikke noget problem.

Om verifikationen sker i hardware eller software er i princippet et fedt: Man skal kunne stole på verifikationen i begge tilfælde. Og det er absurd at påstå, at man bedre kan stole på korrektheden af hardware end på korrektheden af software.

Problemet ligger ikke egentlig i kompleksitet: Sålænge denne kompleksitet er opbygget af komponenter med verificerede kontrakter, så kan man være sikker på, at den kombinerede kontrakt er opfyldt -- uanset hvor kompleks denne måtte være. Det kræver blot regler til kombination af kontrakter for sammensatte komponenter til en samlet kontrakt, og at verificere at den samlede kontrakt er en instans af en på forhånd givet sikkerhedskontrakt. Men det er der masser af formalismer for. Google evt. efter "contract calculus".

Det, der er kernen i sikkerhedsproblemerne i moderne systemer er, at kontrakterne er for løse, at de ikke er eksplicitte, og at komponenter ikke verificeres for overholdelse af deres kontrakter.

Hvis vi tager buffer overflow som eksempel, så er der i mange systemer ingen kontrol af, om programmer laver buffer overflow. Man kan sikre dette på flere niveauer: I hardware med memory protection, i en virtuel maskine med bounds checking, i en compiler ved at verificere, at alle tilgange til en buffer er indenfor grænserne. I det første tilfælde, er det hardwaren, der skal overholde en kontrakt, i det andet er det den virtuelle maskine og i det tredje er det det oversatte program. Compileren kan som en del af sin kontrakt garantere, at de oversatte programmer overholder deres kontrakt, men hvis man får programmer udefra, skal de lokalt verificeres for opfyldelse af deres kontrakter inden, de køres.

  • 3
  • 0
Johannes Ulfkjær Jensen

Det var da utroligt meget du kunne skrive og samtidig være totalt off topic. Det har ikke noget med kontrakter, verifikation eller lign. at gøre. Interviewet handler simpelthen om at efter at have presset grænsen til hvad der lader sig gøre i software kigger de nu på hvad der kan gøres i hardware for at afhjælpe situationen.

  • 0
  • 4
Poul-Henning Kamp Blogger

Problemet med Java er, at man hældte en masse nye features og optimeringer [...]

Det er hvad vi andre ville udtrykke "Problemet med Java var at det blev brugt [...]"

Hvis ikke arkitekturen er lavet så de isolerede små kritiske dele forbliver små isolerede dele, så er det første sikkerhedshul kun et spørgsmål om tid.

For så vidt alt talen om kontrakter osv, så er jeg uenig. Langt de fleste sikkerhedsbrister skyldes fejl, sjusk og anden elendighed og det retter kontrakter og andet papirnusseri ikke op på, de kan kun forbedres med kompetence & tid.

  • 0
  • 0
Jacob Christian Munch-Andersen

Hvis ikke arkitekturen er lavet så de isolerede små kritiske dele forbliver små isolerede dele, så er det første sikkerhedshul kun et spørgsmål om tid.

Helt enig, og derfor er det bydende nødvendigt at størstedelen af de funktioner som man finder i et sprog som Java bliver kørt i sandkassen. Ideen med lige at træde udenfor for at spare et par cycles må dø.

  • 0
  • 0
Torben Mogensen Blogger

Hvis ikke arkitekturen er lavet så de isolerede små kritiske dele forbliver små isolerede dele, så er det første sikkerhedshul kun et spørgsmål om tid.

Hvis de er helt isolerede fra hinanden, kan de ikke arbejde sammen. Derfor skal de kunne kommunikere med hinanden via lager, APIer, protokoller eller lignende. Og disse kommunikationsmuligheder skal være veldefineret, og det skal sikres, at det er den eneste måde andre dele af systemet kan kommunikere med denne del.

Er det ikke nærmest definitionen af en kontrakt? Det væsentligste er, at det sikres at kontrakten overholdes. Til dette kan man bruge både hardware og software.

For så vidt alt talen om kontrakter osv, så er jeg uenig. Langt de fleste sikkerhedsbrister skyldes fejl, sjusk og anden elendighed og det retter kontrakter og andet papirnusseri ikke op på, de kan kun forbedres med kompetence & tid.

En kontrakt, der verificeres, før eller mens et program får lov at køre, sikrer mod, at sjusk og elendighed får et program til at bryde kontrakten. Hvis kontrakten netop definerer sikkerhedsbegrebet, kan det forhindre brug på dette sikkerhedsbegreb. Det kræver selvfølgelig, at sikkerhed er veldefineret. Men uden klarhed over dette kan man alligevel ikke lave andet end en illusion af sikkerhed.

Du kalder kontrakter for "papirnusseri". Men det er netop ikke bare noget, man skriver ned på et papir og lægger i skuffen. Det er noget, der maskinelt overvåges og verificeres, hver gang komponenter interagerer. Om denne overvågning sker i hardware eller software er underordnet. Grænsen mellem hardware og software er alligevel ret flydende efterhånden.

  • 0
  • 0
Torben Mogensen Blogger

Hvis kontrakter virkede, ville vi ikke have brug for Sø og Handelsretten.

Nu er du vist bevidst tungnem. Jeg taler ikke om kontrakter mellem mennesker, skrevet på en variant af dansk eller engelsk ("legalese"), men om en formel kontrakt skrevet i et veldefineret (og afgørligt) kontraktsprog. Se for eksempel www.diku.dk/hjemmesider/ansatte/hvitved/publications/hvitved12phd.pdf

  • 2
  • 0
Log ind eller Opret konto for at kommentere