WebAssembly skyver Googles PNaCl ut i kulden

[Harald Brombach (digi.no)]

WebAssembly skyver Googles PNaCl ut i kulden

[Emancipate]

På weben har dette historisk blitt løst ved å bruke plugins som Java, Flash eller Silverlight. Flash lever fortsatt, men de øvrige pluginteknologiene er i praksis døde, siden stadig færre nettlesere har støtte for dem.

Ingen av disse er noe mer native.

[Gjest Slettet-Pqy3rC]

Få ting i en browser kan egentlig være "ekte" native, sånt blir rimelig fort en sikkerhetsrisiko.

[Per Buer]

Få ting i en browser kan egentlig være "ekte" native, sånt blir rimelig fort en sikkerhetsrisiko.

 

Tja. Jeg mener at vi temmelig enkelt vil kunne gjøre native code som kjører rett på CPUen hvis det er det vi virkelig vil.

 

Hvis vi kan bruke maskinvarevirtualiseringen i moderne CPUer til å eksekvere koden så garanterer maskinvaren at dette holdes isolert. Da kan du laste ned binærkode og noe metadata som så bootes opp i en liten VM. Dette tar jo ikke mer enn noen få millisekunder å initialisere. Nettleseren trenger tilgang til å starte VMen via OSet sitt grensesnitt (KVM, com.apple.vm.hypervisor og hva nå dette heter på windows).

 

Så trenger denne VMen en måte å få data inn og ut. Hvis vi gir VMen en grensesnitt for å gjøre HTTP-kall mot serveren som image ble hentet ned fra så slipper vi en haug med problemer (merk: ingen generisk IP-aksess).

 

I tillegg så trenger VM'en en måte å manipulere DOM på den siden den tilhører. Så du trenger en mekanisme for å gjøre dette.

 

Begge disse grensesnittene tror jeg kan implementeres over VMCALL-instruksjonen. Alt i alt er dette såpass minimalistiske grensesnitt at det ikke er noe stort problem å gjøre det sikkert.

 

Med noe slikt så kunne en fint kjørt C/C++/Go/Whatever rett på CPUen på en oppimot 100% sikker måte. Det blir iallfall en langt sikrere arkitektur enn hva dagens web-arkitektur medfører. Nettleserene gjør jo langt mer interaksjon med data hentet fra ukjente og potensielt ondsinnede tjenester.

 

En trenger et minimalistisk OS som disse VMene skal kjøre. Her er det flere kandidater men IncludeOS hadde jo fungert fint til noe slikt.

[Gjest Slettet-Pqy3rC]

Tja. Jeg mener at vi temmelig enkelt vil kunne gjøre native code som kjører rett på CPUen hvis det er det vi virkelig vil.

...

En trenger et minimalistisk OS som disse VMene skal kjøre. Her er det flere kandidater men IncludeOS hadde jo fungert fint til noe slikt.

Uhm... Når jeg nevte "native" over tenkte jeg i første rekke på "OS Native". Altså kunne utnytte (enkelte) ressurser tilgjengelig for OS'et browseren startes fra. Det er en "smal sti å gå".

 

Men ja, får browseren funksjonalitet for å kontollere/kommandere en os hypervisor så er jo ditt scenario mulig. Dog bør det fungere rimelig 100% ellers ender en fort med ressurs spisende daemons som muligens ikke er så helt lette å oppdage...

[Per Buer]

Men ja, får browseren funksjonalitet for å kontollere/kommandere en os hypervisor så er jo ditt scenario mulig. Dog bør det fungere rimelig 100% ellers ender en fort med ressurs spisende daemons som muligens ikke er så helt lette å oppdage...

 

Ja. Men det er ikke verre en hvilken som helst annen prosess. For verten vil det i hovedsak se ut som en vanlig prosess som får minne og CPU fra OS'et. Hvis du har kjørt qemu/kvm på Linux så har du sett det. Eneste forskjellen er at maskinvaren gjør langt mer for å isolere den prosessen fra resten av systemet - så du har ikke systemkall og andre OS-funksjoner tilgjengelig.

 

Dog vil du ikke ha så mye mulighet til å kikke inn i den prosessen. Men det er uansett noe de færreste ha behov for.

[JanJohan]

 

Få ting i en browser kan egentlig være "ekte" native, sånt blir rimelig fort en sikkerhetsrisiko.

 

Tja. Jeg mener at vi temmelig enkelt vil kunne gjøre native code som kjører rett på CPUen hvis det er det vi virkelig vil.

 

Hvis vi kan bruke maskinvarevirtualiseringen i moderne CPUer til å eksekvere koden så garanterer maskinvaren at dette holdes isolert. Da kan du laste ned binærkode og noe metadata som så bootes opp i en liten VM. Dette tar jo ikke mer enn noen få millisekunder å initialisere. Nettleseren trenger tilgang til å starte VMen via OSet sitt grensesnitt (KVM, com.apple.vm.hypervisor og hva nå dette heter på windows).

 

Så trenger denne VMen en måte å få data inn og ut. Hvis vi gir VMen en grensesnitt for å gjøre HTTP-kall mot serveren som image ble hentet ned fra så slipper vi en haug med problemer (merk: ingen generisk IP-aksess).

 

I tillegg så trenger VM'en en måte å manipulere DOM på den siden den tilhører. Så du trenger en mekanisme for å gjøre dette.

 

Begge disse grensesnittene tror jeg kan implementeres over VMCALL-instruksjonen. Alt i alt er dette såpass minimalistiske grensesnitt at det ikke er noe stort problem å gjøre det sikkert.

 

Med noe slikt så kunne en fint kjørt C/C++/Go/Whatever rett på CPUen på en oppimot 100% sikker måte. Det blir iallfall en langt sikrere arkitektur enn hva dagens web-arkitektur medfører. Nettleserene gjør jo langt mer interaksjon med data hentet fra ukjente og potensielt ondsinnede tjenester.

 

En trenger et minimalistisk OS som disse VMene skal kjøre. Her er det flere kandidater men IncludeOS hadde jo fungert fint til noe slikt.

Kan ikke stort om dette, men er nysgjerrig. I en slik løsning med VM som du skisserer, da kjører jo alt i sin egen lille boble. Men hvordan håndtere sikker aksess til felles ressurser som disk, skjerm, USB, etc?

[G]

Det var vel et nylig eksempel at en virtuell maskin ikke var så sikker likevel (VMware som var berørt). Men jeg husker å ha lest at det var en svært intrikat metode som måtte til for å finne og utnytte den. Et kjapt Google-søk fikk opp denne, så kan hende det er samme historie som jeg lesten enten om på Tek.no eller Digi.no:

 

https://threatpost.com/vmware-patches-pwn2own-vm-escape-vulnerabilities/124629/

Endret 2. juni 2017 av G

[Per Buer]

Det var vel et nylig eksempel at en virtuell maskin ikke var så sikker likevel (VMware som var berørt). Men jeg husker å ha lest at det var en svært intrikat metode som måtte til for å finne og utnytte den. Et kjapt Google-søk fikk opp denne, så kan hende det er samme historie som jeg lesten enten om på Tek.no eller Digi.no:

 

https://threatpost.com/vmware-patches-pwn2own-vm-escape-vulnerabilities/124629/

Problemet med virtuelle maskiner har vært emuleringen som frem til idag har vært essensiell for å få dem til å fungere. Qemu, som brukes til å emulere maskinen som KVM bruker for å gi deg en virtuell maskin er et beist av en kodebase og VENOM viste i 2015 hvordan en feil i Qemu kunne brukes for å bryte ut av en VM. De feilene du viser til er feil i den emulerte maskinvaren. Den emulerte maskinvaren kjører utenom VM'en selv og der har du problemet.

 

Men meg bekjent er det frem til idag ikke funnet noen møte du kan bryte ut av den maskinvarebaserte VM'en som CPUen gir deg (direkte). Den eneste måten ut er gjennom grensesnittene som den emulerte maskinvaren (Qemu) gir deg.

 

Hvis Chrome skulle ønske å bruke maskinvarebasert virtualisering så er det helt sentralt at de gjør dette på en langt lettere måte enn hva f.eks. Qemu eller vmware gjør. De må tilby helt minimale grensesnitt. Det er ikke noe poeng i at det er en PCI-buss, IDE-disker eller annen hardware. Hvis Chrome skal ha VM'er så trenger ikke disse å kjøre noe General Purpose OS. De trenger bare et helt minimalt grensesnitt for å boote en minimal VM med veldig godt definerte og spesialiserte grensesnitt mot omverdenen.

 

Dette er jeg helt overbevist om at en kan gjøre på en veldig sikker måte. Langt sikrere enn f.eks. parsing av HTML.

 

Vi skulle gjerne gjort det - men det har ingen kommersiell verdi for oss å gjøre det. Dessuten greier vi neppe (alene) å etablere en standard.

Endret 2. juni 2017 av Per Buer

[Per Buer]

Kan ikke stort om dette, men er nysgjerrig. I en slik løsning med VM som du skisserer, da kjører jo alt i sin egen lille boble. Men hvordan håndtere sikker aksess til felles ressurser som disk, skjerm, USB, etc?

Poenget mitt er at du trenger ikke dette. Dette blir et veldig spesialisert operativsystem som ikke skal kunne kjøre Windows eller Linux. Det skal kjøre en helt minimal applikasjon som skal tilby rask og effektiv lokal behandling av data.

 

Bruksområdet for noe slikt kunne være f.eks. dekompressjon av video. Du går på en webside som henter ned en liten VM som utelukkende kan prate med serveren den hentet VM'en fra. Her henter den video (eller andre data) som så behandles med direkte tilgang til CPU og bruker maskinvaren i CPUen for hva denne er verdt.

 

Når dataene så er behandlet så må VMen tilgjengliggjøre dissse dataene for nettleseren. Dette gjøres med delt minne eller tilsvarende. Her er det viktig at grensesnittene er enkle nok til at vi kan gjøre formell verifikasjon av dem slik at vi kan være sikre på at det ikke er noen måte VM'en kan lure chrome til å eksekvere kode utenfor VM'en.

 

Hvis en lar VMen få tilgang til å sende vilkårlige pakker på nettverket så har du jo tapt. Da vil VMen din raskt bli en del av et bot-nett og sette igang med å lage helvete.