En grundig titt på disse farlige utnyttelsene av mikroprosessorens sårbarheter og hvorfor det kan være flere av dem der ute
Vi er vant til å tenke på dataprosessorer som ordnede maskiner som går fra en enkel instruksjon til den neste med fullstendig regelmessighet. Men sannheten er, at i flere tiår nå, de har gjort sine oppgaver ute av drift og bare gjette på hva som skal komme neste. De er veldig gode på det, selvfølgelig. Så bra faktisk at denne evnen, kalt spekulativ utførelse, har støttet mye av forbedringen i datakraft i løpet av de siste 25 årene eller så. Men den 3. januar 2018 lærte verden at dette trikset, som hadde gjort så mye for moderne databehandling, nå var en av sine største sårbarheter.
gjennom 2017 utarbeidet forskere Ved Cyberus Technology, Google Project Zero, Graz University Of Technology, Rambus, University Of Adelaide og University Of Pennsylvania, samt uavhengige forskere som kryptograf Paul Kocher, separat angrep som utnyttet spekulativ utførelse. Vår egen gruppe hadde oppdaget den opprinnelige sårbarheten bak et av disse angrepene tilbake i 2016, men vi satte ikke alle bitene sammen.
Disse typer angrep, Kalt Meltdown og Spectre, var ingen vanlige bugs. På den tiden Det ble oppdaget, Meltdown kunne hacke Alle Intel x86 mikroprosessorer OG IBM Power-prosessorer, samt NOEN ARM-baserte prosessorer. Spectre og dets mange variasjoner la Til Advanced Micro Devices (AMD) prosessorer til den listen. Med andre ord var nesten hele verden av databehandling sårbar.
og fordi spekulativ utførelse i stor grad er bakt inn i prosessormaskinvare, har det ikke vært lett å fikse disse sikkerhetsproblemene. Å gjøre det uten å få databehandlingshastigheter til å slipe inn i lavt gir har gjort det enda vanskeligere. Etter et år er jobben langt fra over. Sikkerhetsoppdateringer var nødvendig ikke bare fra prosessorprodusentene, men fra de lenger ned i forsyningskjeden, Som Apple, Dell, Linux og Microsoft. De første datamaskinene drevet av chips som er bevisst utformet for å være motstandsdyktig mot selv noen av disse sikkerhetsproblemene kom bare nylig.
Spectre og Meltdown er resultatet av forskjellen mellom hva programvare skal gjøre og prosessorens mikroarkitektur—detaljene om hvordan det faktisk gjør disse tingene. Disse to klassene av hack har avdekket en måte for informasjon å lekke ut gjennom den forskjellen. Og det er all grunn til å tro at flere måter vil bli avdekket. Vi hjalp til med å finne To, Branchscope og SpectreRSB , i fjor.
Hvis vi skal holde tempoet i databehandlingsforbedringer uten å ofre sikkerheten, må vi forstå hvordan disse maskinvaresårbarhetene skjer. Og det begynner med Å forstå Spectre og Meltdown.
i moderne datasystemer er programvare skrevet på menneskelig forståelige språk som C++ kompilert i monteringsspråklige instruksjoner-grunnleggende operasjoner som datamaskinprosessoren kan utføre. For å få fart på utførelsen bruker moderne prosessorer en tilnærming som kalles pipelining. Som et samlebånd er rørledningen en rekke trinn, som hver er et trinn som trengs for å fullføre en instruksjon. Noen typiske stadier For En Intel x86-prosessor inkluderer de som tar inn instruksjonen fra minnet og dekoder det for å forstå hva instruksjonen betyr. Pipelining bringer i utgangspunktet parallellisme ned til instruksjonsnivået: Når en instruksjon er ferdig ved hjelp av et stadium, er neste instruksjon gratis å bruke den.
siden 1990-tallet har mikroprosessorer stolt på to triks for å øke hastigheten på rørledningsprosessen: utføring av ordre og spekulasjon. Hvis to instruksjoner er uavhengige av hverandre – det vil si at utgangen av en ikke påvirker inngangen til en annen-de kan omordnes og resultatet vil fortsatt være riktig. Det er nyttig, fordi det gjør at prosessoren kan fortsette å jobbe hvis en instruksjon boder i rørledningen. For eksempel, hvis en instruksjon krever data som er ute I dram-hovedminnet i stedet for i hurtigbufferminnet som ligger i SELVE CPUEN, kan det ta noen hundre klokkesykluser for å få dataene. I stedet for å vente, kan prosessoren flytte en annen instruksjon gjennom rørledningen.
det andre trikset er spekulasjon. For å forstå det, begynn med det faktum at noen instruksjoner nødvendigvis fører til en endring i hvilke instruksjoner som kommer neste. Vurder et program som inneholder en» hvis » – setning: den sjekker for en tilstand, og hvis tilstanden er sant, hopper prosessoren til et annet sted i programmet. Dette er et eksempel på en betinget filialinstruksjon, men det finnes andre instruksjoner som også fører til endringer i instruksjonsstrømmen.
vurder nå hva som skjer når en slik filialinstruksjon går inn i en rørledning. Det er en situasjon som fører til en gåte. Når instruksjonen kommer i begynnelsen av rørledningen, vet vi ikke utfallet før det har kommet ganske dypt inn i rørledningen. Og uten å vite dette utfallet, kan vi ikke hente neste instruksjon. En enkel, men naiv løsning er å forhindre at nye instruksjoner kommer inn i rørledningen til greninstruksjonen når et punkt der vi vet hvor neste instruksjon kommer fra. Mange klokkesykluser er bortkastet i denne prosessen, fordi rørledninger vanligvis har 15 til 25 trinn. Enda verre, avdelingsinstruksjoner kommer opp ganske ofte, og står for opptil 20 prosent av alle instruksjonene i mange programmer.
for å unngå høye ytelseskostnader ved å stanse rørledningen, bruker moderne prosessorer en arkitektonisk enhet kalt en grensprediktor for å gjette hvor neste instruksjon, etter en gren, kommer fra. Formålet med denne prediktoren er å spekulere om et par viktige punkter. Først vil en betinget gren bli tatt, slik at programmet går av til en annen del av programmet, eller vil det fortsette på den eksisterende banen? Og for det andre, hvis grenen er tatt, hvor skal programmet gå-hva blir neste instruksjon? Bevæpnet med disse spådommene, kan prosessorledningen holdes full.
fordi instruksjonsutførelsen er basert på en prediksjon, blir den utført «spekulativt» : hvis prediksjonen er riktig, forbedres ytelsen betydelig. Men hvis prediksjonen viser seg feil, må prosessoren kunne angre effekten av noen spekulativt utførte instruksjoner relativt raskt.
utformingen av grenen prediktor har vært robust undersøkt i datamaskin-arkitektur samfunnet i mange år. Moderne prediktorer bruker historien om utførelse i et program som grunnlag for deres resultater. Denne ordningen oppnår nøyaktigheter på over 95 prosent på mange forskjellige typer programmer, noe som fører til dramatiske ytelsesforbedringer, sammenlignet med en mikroprosessor som ikke spekulerer. Misspeculation er imidlertid mulig. Og dessverre er det misspeculation Som Spectre-angrepene utnytter.
En annen form for spekulasjon som har ført til problemer er spekulasjon innenfor en enkelt instruksjon i rørledningen. Det er et ganske abstruse konsept, så la oss pakke ut det. Anta at en instruksjon krever tillatelse til å utføre. For eksempel kan en instruksjon lede datamaskinen til å skrive en del data til den delen av minnet som er reservert for kjernen i operativsystemet. Du vil ikke at det skal skje, med mindre det ble sanksjonert av operativsystemet selv, eller du vil risikere å krasje datamaskinen. Før Oppdagelsen Av Meltdown og Spectre var den konvensjonelle visdommen at det er greit å begynne å utføre instruksjonen spekulativt selv før prosessoren har nådd poenget med å sjekke om instruksjonen har tillatelse til å gjøre sitt arbeid.
Til slutt, hvis tillatelsen ikke er fornøyd – i vårt eksempel har operativsystemet ikke sanksjonert dette forsøket på å fla med minnet—resultatene blir kastet ut og programmet indikerer en feil. Generelt kan prosessoren spekulere rundt noen del av en instruksjon som kan føre til at den venter, forutsatt at tilstanden til slutt blir løst og eventuelle resultater fra dårlige gjetninger er effektivt ugjort. Det er denne typen intra-instruksjon spekulasjon som ligger bak alle varianter Av Meltdown bug, inkludert sin uten tvil farligere versjon, Foreshadow.
innsikten som muliggjør spekulasjonsangrep er dette: under feilspekulering skjer det ingen endring som et program direkte kan observere. Med andre ord, det er ikke noe program du kan skrive som bare vil vise data generert under spekulativ utførelse. Men det faktum at spekulasjoner skjer, etterlater spor ved å påvirke hvor lang tid det tar å utføre instruksjoner. Og dessverre er det nå klart at vi kan oppdage disse tidssignalene og trekke ut hemmelige data fra dem.
Hva er denne timinginformasjonen, og hvordan får en hacker tak i den? For å forstå det, må du forstå begrepet sidekanaler. En sidekanal er en utilsiktet vei som lekker informasjon fra en enhet til en annen (vanligvis begge er programmer), vanligvis gjennom en delt ressurs som en harddisk eller et minne.
som et eksempel på et sidekanalangrep, bør du vurdere en enhet som er programmert til å lytte til lyden som kommer fra en skriver, og deretter bruker den lyden til å utlede hva som skrives ut. Lyden, i dette tilfellet, er en sidekanal.
i mikroprosessorer kan enhver delt maskinvareressurs i prinsippet brukes som en sidekanal som lekker informasjon fra et offerprogram til et angriperprogram. I et vanlig sidekanalangrep er den delte ressursen CPUS cache. Cachen er et relativt lite minne med rask tilgang på prosessorbrikken som brukes til å lagre dataene som oftest trengs av et program. Når et program får tilgang til minne, kontrollerer prosessoren først cachen; hvis dataene er der( et cache hit), gjenopprettes det raskt. Hvis dataene ikke er i hurtigbufferen( en glipp), må prosessoren vente til den hentes fra hovedminnet, som kan ta flere hundre klokkesykluser. Men når dataene kommer fra hovedminnet, legges det til hurtigbufferen, noe som kan kreve å kaste ut andre data for å få plass. Cachen er delt inn i segmenter som kalles cachesett, og hvert sted i hovedminnet har et tilsvarende sett i cachen. Denne organisasjonen gjør det enkelt å sjekke om noe er i hurtigbufferen uten å måtte søke hele greia.
Cache-baserte angrep hadde blitt grundig undersøkt selv før Spectre og Meltdown dukket opp på scenen. Selv om angriperen ikke kan lese offerets data direkte—selv når dataene sitter i en delt ressurs som hurtigbufferen—kan angriperen få informasjon om minneadressene som offeret har tilgang til. Disse adressene kan avhenge av sensitive data, slik at en smart angriper kan gjenopprette disse hemmelige dataene.
Hvordan gjør angriperen dette? Det er flere mulige måter. En variant, Kalt Flush og Reload, begynner med at angriperen fjerner delte data fra hurtigbufferen ved hjelp av» flush » – instruksjonen. Angriperen venter på at offeret skal få tilgang til dataene. Fordi det ikke lenger er i hurtigbufferen, må alle data som offeret ber om, hentes inn fra hovedminnet. Senere får angriperen tilgang til delte data mens timing hvor lang tid dette tar. En cache hit-noe som betyr at dataene er tilbake i cachen-indikerer at offeret fikk tilgang til dataene. En cache miss indikerer at dataene ikke har blitt åpnet. Så, bare ved å måle hvor lang tid det tok å få tilgang til data, kan angriperen bestemme hvilke cache-sett som ble åpnet av offeret. Det tar litt algoritmisk magi, men denne kunnskapen om hvilke cache-sett som ble åpnet, og som ikke var, kan føre til oppdagelse av krypteringsnøkler og andre hemmeligheter.
Meltdown, Spectre og deres varianter følger alle samme mønster. Først utløser de spekulasjoner for å utføre kode ønsket av angriperen. Denne koden leser hemmelige data uten tillatelse. Deretter kommuniserer angrepene hemmeligheten ved Hjelp Av Flush og Reload eller en lignende sidekanal. Den siste delen er godt forstått og lignende i alle angrepsvariasjonene. Dermed varierer angrepene bare i den første komponenten, som er hvordan man utløser og utnytter spekulasjon.
Meltdown Angrep
Meltdown angrep utnytte spekulasjon innenfor en enkelt instruksjon. Selv om monteringsspråk instruksjoner er vanligvis enkel, en enkelt instruksjon består ofte av flere operasjoner som kan avhenge av hverandre. Minneleseoperasjoner er for eksempel ofte avhengig av instruksjonen som tilfredsstiller tillatelsene knyttet til minneadressen som leses. Et program har vanligvis tillatelse til å lese bare fra minne som er tildelt det, ikke fra minne som er tildelt operativsystemet eller en annen brukers program. Logisk bør vi sjekke tillatelsene før vi lar lesingen fortsette, noe som noen mikroprosessorer gjør, spesielt DE FRA AMD. Men forutsatt at sluttresultatet er riktig, ANTOK CPU-designere at DE var fri til å spekulativt utføre disse operasjonene ute av drift. Derfor leser Intel-mikroprosessorer minneplasseringen før du sjekker tillatelser, men bare «forplikte» instruksjonen—gjør resultatene synlige for programmet—når tillatelsene er oppfylt. Men fordi de hemmelige dataene er hentet spekulativt, kan De oppdages ved hjelp av en sidekanal, Noe Som gjør Intel-prosessorer sårbare for dette angrepet.
Foreshadow-angrepet er en variant av Meltdown-sårbarheten. Dette angrepet påvirker Intel mikroprosessorer på grunn Av en svakhet Som Intel refererer Til Som L1 Terminal Fault (L1TF). Mens det opprinnelige Meltdown-angrepet stod på en forsinkelse i å sjekke tillatelser, er Foreshadow avhengig av spekulasjoner som oppstår under et stadium av rørledningen kalt adresseoversettelse.
Programvare ser datamaskinens minne og lagringsressurser som en enkelt sammenhengende strekning av virtuelt minne helt eget. Men fysisk er disse eiendelene delt opp og delt mellom ulike programmer og prosesser. Adresseoversettelse gjør en virtuell minneadresse til en fysisk minneadresse.
Spesialiserte kretser på mikroprosessoren hjelper med den virtuelle til fysiske minneadresseoversettelsen, men det kan være sakte, og krever flere minneoppslag. For å få fart på ting, Tillater Intel mikroprosessorer spekulasjon under oversettelsesprosessen, slik at et program spekulativt kan lese innholdet I En del Av cachen Kalt L1, uavhengig av hvem som eier dataene. Angriperen kan gjøre dette, og deretter avsløre dataene ved hjelp av sidekanaltilnærmingen vi allerede har beskrevet.
På noen måter Er Foreshadow farligere enn Meltdown, på andre måter er det mindre. I motsetning Til Meltdown kan Foreshadow bare lese innholdet I l1-cachen, på grunn Av Detaljene I Intels implementering av prosessorarkitekturen. Men Foreshadow kan lese noe innhold I L1-ikke bare data adresseres av programmet.
Spectre Angrep
Spectre angrep manipulere grenen-prediksjon system. Dette systemet har tre deler: gren-retning prediktor, gren-mål prediktor, og retur stabel buffer.
branch-direction predictor spår om en betinget gren, for eksempel en som brukes til å implementere en «hvis» – setning i et programmeringsspråk, vil bli tatt eller ikke tatt. For å gjøre dette sporer den tidligere oppførselen til lignende grener. For eksempel kan det bety at hvis en gren tas to ganger på rad, vil fremtidige spådommer si at den skal tas.
branch-target predictor spår målminne adressen til det som kalles indirekte grener. I en betinget gren er adressen til neste instruksjon stavet ut, men for en indirekte gren må adressen beregnes først. Systemet som forutsier disse resultatene, er en bufferstruktur kalt grenmålbufferen. I hovedsak holder den styr på det siste beregnede målet for de indirekte grenene og bruker disse til å forutsi hvor neste indirekte gren skal føre til.
returstakkbufferen brukes til å forutsi målet for en» retur » – instruksjon. Når en subrutine er «kalt» under et program, gjør retur instruksjon programmet gjenoppta arbeidet på det punktet som subrutinen ble kalt. Prøver å forutsi riktig punkt å gå tilbake til basert bare på tidligere returadresser vil ikke fungere, fordi den samme funksjonen kan kalles fra mange forskjellige steder i koden. I stedet bruker systemet returstakkbufferen, et minne på prosessoren, som holder returadressene til funksjoner som de kalles. Den bruker deretter disse adressene når det oppstår en retur i subrutineens kode.
Hver av disse tre strukturene kan utnyttes på to forskjellige måter. For det første kan prediktoren bevisst mistrained. I dette tilfellet utfører angriperen tilsynelatende uskyldig kode designet for å forvirre systemet. Senere utfører angriperen bevisst en gren som vil misspekulere, slik at programmet hopper til et stykke kode valgt av angriperen, kalt en gadget. Gadgeten setter da om å stjele data.
en annen Måte Av Spectre angrep kalles direkte injeksjon. Det viser seg at under noen forhold deles de tre prediktorene mellom ulike programmer. Hva dette betyr er at det angripende programmet kan fylle prediktorstrukturer med nøye utvalgte dårlige data som det utfører. Når et uvitende offer utfører sitt program enten samtidig som angriperen eller etterpå, vil offeret ende opp med å bruke prediktorstaten som ble fylt ut av angriperen og ubevisst satt av en gadget. Dette andre angrepet er spesielt bekymringsfullt fordi det tillater et offerprogram å bli angrepet fra et annet program. En slik trussel er spesielt skadelig for skytjenesteleverandører fordi de ikke kan garantere at deres klientdata er beskyttet.
Spectre og Meltdown sårbarheter presentert en gåte til dataindustrien fordi sårbarheten stammer i maskinvare. I noen tilfeller er det beste vi kan gjøre for eksisterende systemer—som utgjør hoveddelen av installerte servere og Pcer-å prøve å omskrive programvare for å forsøke å begrense skaden. Men disse løsningene er ad hoc, ufullstendig, og ofte resultere i en stor hit til datamaskinens ytelse. Samtidig har forskere og CPU-designere begynt å tenke på hvordan å designe fremtidige Cpuer som holder spekulasjon uten å gå på kompromiss med sikkerheten.
ett forsvar, kalt kernel page-table isolation (KPTI), er nå innebygd I Linux og andre operativsystemer. Husk at hvert program ser datamaskinens minne og lagring eiendeler som en enkelt sammenhengende strekning av virtuelt minne alle sine egne. Men fysisk er disse eiendelene delt opp og delt mellom ulike programmer og prosesser. Sidetabellen er i hovedsak operativsystemets kart, og forteller det hvilke deler av en virtuell minneadresse som samsvarer med hvilke fysiske minneadresser. Kjernesidetabellen er ansvarlig for å gjøre dette for kjernen i operativsystemet. KPTI og lignende systemer forsvarer Seg mot Nedsmelting ved å gjøre hemmelige data i minnet, for EKSEMPEL OPERATIVSYSTEMET, utilgjengelige når en brukers program (og potensielt angriperens program) kjører. Det gjør dette ved å fjerne de forbudte delene fra sidetabellen. På den måten kan selv spekulativt utført kode ikke få tilgang til dataene. Denne løsningen betyr imidlertid ekstra arbeid for operativsystemet for å kartlegge disse sidene når det utføres og unmap dem etterpå.
En annen klasse av forsvar gir programmerere et sett med verktøy for å begrense farlig spekulasjon. For Eksempel omskriver Googles Retpoline patch den typen grener som er sårbare For Spectre Variant 2, slik at det tvinger spekulasjon til å målrette mot en godartet, tom gadget. Programmerere kan også legge til en assembly-språk instruksjon som begrenser Spectre v1, ved å begrense spekulative minne leser som følger betingede grener. Praktisk er denne instruksjonen allerede til stede i prosessorarkitekturen og brukes til å håndheve riktig bestilling mellom minneoperasjoner som kommer fra forskjellige prosessorkjerner.
Som prosessordesignere måtte Intel og AMD gå dypere enn en vanlig programvareoppdatering. Deres fikser oppdaterer prosessorens mikrokode. Mikrokode er et lag med instruksjoner som passer mellom monteringsspråket til vanlig programvare og prosessorens faktiske kretser. Mikrokode gir fleksibilitet til settet med instruksjoner en prosessor kan utføre. Det gjør det også enklere å designe EN CPU fordi når du bruker mikrokode, blir komplekse instruksjoner oversatt til flere enklere instruksjoner som er enklere å utføre i en rørledning.
I Utgangspunktet justerte Intel og AMD sin mikrokode for å endre oppførselen til noen monteringsspråklige instruksjoner på måter som begrenser spekulasjon. For Eksempel har Intel-ingeniører lagt til alternativer som forstyrrer noen av angrepene ved å la operativsystemet tømme gren-prediktorstrukturer under visse omstendigheter.
en annen klasse av løsninger forsøker å forstyrre angriperens evne til å overføre dataene ved hjelp av sidekanaler. FOR eksempel deler MITS DAWG-teknologi sikkert opp prosessorbufferen slik at forskjellige programmer ikke deler noen av ressursene. Mest ambisiøst er det forslag til nye prosessorarkitekturer som vil introdusere strukturer på CPUEN som er dedikert til spekulasjon og skilt fra prosessorens cache og annen maskinvare. På denne måten er alle operasjoner som utføres spekulativt, men ikke til slutt begått, aldri synlige. Hvis spekulasjonsresultatet er bekreftet, sendes spekulative data til prosessorens hovedstrukturer.
Spekulasjonsproblemer har ligget sovende i prosessorer i over 20 år, og de forblir, så langt som noen vet, uutnyttet. Deres oppdagelse har vesentlig rystet industrien og fremhevet hvordan cybersikkerhet ikke bare er et problem for programvaresystemer, men også for maskinvare. Siden den første oppdagelsen har rundt et dusin varianter Av Spectre og Meltdown blitt avslørt, og det er sannsynlig at det er flere. Spectre og Meltdown er tross alt bivirkninger av kjernedesignprinsipper som vi har stolt på for å forbedre datamaskinens ytelse, noe som gjør det vanskelig å eliminere slike sårbarheter i dagens systemdesign. Det er sannsynlig at NYE CPU-design vil utvikle seg for å beholde spekulasjon, samtidig som det forhindrer typen sidekanallekkasje som muliggjør disse angrepene. Ikke desto mindre må fremtidige datasystemdesignere, inkludert de som designer prosessorbrikker, være oppmerksomme på sikkerhetsimplikasjonene av sine beslutninger, og ikke lenger optimalisere bare for ytelse, størrelse og kraft.
Om Forfatteren
Nael Abu-Ghazaleh er leder av computer engineering program Ved University Of California, Riverside. Dmitry Evtyushkin er assisterende professor i datavitenskap Ved College Of William And Mary, I Williamsburg, Va. Dmitry Ponomarev er professor i datavitenskap ved State University Of New York I Binghamton.
For Å Undersøke Videre
Paul Kocher og de andre forskerne som kollektivt avslørte Spectre, forklarte Det først her. Moritz Lipp forklarte Meltdown i denne talen På Usenix Security ’18. Foreshadow ble detaljert på samme konferanse.
En gruppe forskere inkludert en av forfatterne har kommet opp med en systematisk evaluering Av Spectre og Meltdown angrep som avdekker flere potensielle angrep . IBM-ingeniører gjorde noe lignende, Og Google-ingeniører kom nylig til den konklusjonen at sidekanal og spekulative utførelsesangrep er her for å bli .