Meltdown og Spectre nedsmeltede gamle ideer om it-sikkerhed i 2018

Illustration: Lasse Gorm Jensen
Gode intentioner om at udføre programmer hurtigere ved at gemme værdier lokalt, omordne instruktioner og gætte på udfald af forgreninger ligger bag nuværende og fremtidige sikkerhedsproblemer i CPU'er.

2018 var knap kommet i gang, før ét af computerhistoriens værste sikkerhedshuller kom til offentlighedens kendskab. Historien breakede tæt på midnat dansk tid, og så måtte Version2's journalist skrotte den planlagte nattesøvn til fordel for nyhedsdækning til langt ud på morgenen 4. januar.

Det var også en brat opvågning for andre, nemlig en branche, der er vant til, at problemer findes i programkode, som kan ændres efter forgodtbefindende.

De nye afsløringer handlede imidlertid ikke om kode, men om instruktioner og teknikker i processorerne, der udgør hjertet i vore dages computerarkitektur.

De to huller, der har fået navnene 'Meltdown' og 'Spectre', findes i de fleste moderne CPU'er. Ved at bruge de helt lovlige instruktioner, som CPU'en stiller til rådighed, kan et program læse fra den 'hemmelige' del af systemets hukommelse. Det giver mulighed for at aflæse kodeord og alle andre slags privilegerede oplysninger – kort sagt et tag-selv-bord for ondsindede programmer.

Forskerne bag afdækningen kunne demonstrere, hvorledes sårbarheden kan udnyttes fra et Javascript-program på en webside i browseren. Og det var den grelle oplysning, der fik journalisten ud af dynerne i den mørke januarnat.

Forudse forgreningen

Teknikken benytter et 'side channel-angreb', hvor der ikke er tale om deciderede fejl i hardwaren. I stedet benyttes andre typer af information, som i forbindelse med Meltdown og Spectre handler om den tid, det tager at læse fra hukommelsen, i modsætning til chippens eget cache-lager.

De to centrale faciliteter, som sårbarhederne udnytter, er caching og spekulativ udførelse af instrukser. Cache, også kendt som L1-, L2- og L3-cache, er i denne forbindelse et lager, som sidder på selve CPU-chippen. Cachen kan tilgås omkring 100 gange hurtigere end selve hukommelsen i RAM, så det giver god mening at kopiere den hukommelse, som CPU'en er i gang med at behandle.

Den anden facilitet er spekulativ udførelse. Det går kort sagt ud på at benytte noget af den tid, hvor CPU'en ellers er i tomgang, til at udføre instruktioner, der måske skal bruges til noget – på den anden side af en 'if'-sætning. Moderne CPU-kerner kan nemlig udføre mere end én instruktion ad gangen, men det er kun muligt at fylde de rørledninger, der føder instruktioner ind i CPU'en, hvis instruktionerne er indbyrdes uafhængige.

Hvis den ene rørledning står med hænderne tomme, kan det give mening at foretage 'spekulativ udførelse' – altså at bruge den overskydende tid på at foretage beregninger, der ligger på den anden side af en forgrening – en if-sætning. CPU'en bruger statistik til at gætte på, om en forgrening udføres eller ej.

Hvis beregningerne alligevel ikke skal bruges, kan man blot smide dem ud, og der er ingen skade sket. Sådan har CPU-producenterne i hvert fald tænkt.

Virkeligheden er, som så ofte før, mere kompleks.

Cache

En moderne processor bruger måske i omegnen af et halvt nanosekund på at foretage en udregning, men det tager op til 100 nanosekunder at hente en byte i hukommelsen. Derfor kopieres værdier fra lageret ind i cachen, hvor læsetiden er omkring ét nanosekund. Taktikken er, at hvis programmet læser fra en adresse i hukommelsen, læser den nok også byten ved siden af.

Ved at narre CPU'en til at tro, at en forgrening finder sted, kan den manipuleres til at foretage beregninger, der involverer den privilegerede, 'hemmelige' hukommelse, i et adresse-udtryk, der peger på programmets egen hukommelse. Den uretmæssige tilgang vil blive opdaget, men den stopklods kan man snyde sig udenom. Ved beregningen er ikke bare én bestemt byte hentet ind i cachen, men også nabobytes, som altså findes i programmets egen del af hukommelsen. Efter fejlen er kommet og gået, kan programmet uhindret læse værdien af de pågældende nabobytes.

Hvis det går hurtigt, omkring 1 nanosekund, må værdien være i cachen. Hvis det tager omkring 100 nanosekunder, er værdien ikke i cachen. Det giver oplysning om værdien af hukommelsen på adressen i den privilegerede del, og på den måde kan et sted i den privilegerede hukommelse læses, én bit ad gangen.

Der er, så vidt vides, ikke fundet virus og malware, der bygger på Meltdown og Spectre. Det betyder dog ikke, at den slags ikke findes. Der er i hvert fald ikke eksempler på større angreb, foretaget ved hjælp af de to sårbarheder, i det forløbne år. Men statslige aktører har i de seneste par år meldt sig som særdeles avancerede producenter af malware, der ikke nødvendigvis kan opdages så let.

De to sårbarheder har eksisteret i Intel-CPU'er de sidste 20 år. Sikkerhedsforskere mente i januar, at flere side channel-huller ville dukke op. Den spådom er til fulde blevet opfyldt. Året igennem har en lang række beslægtede sikkerhedshuller meldt sig på banen.

Kilden til problemet ligger inde i CPU'en og kan fjernes ved blot at slå den spekulative udførelse fra. Det tager til gengæld også 20 til 30 procent af ydelsen. Både Intel og producenterne af styresystemer har udsendt rettelser, men problemet kan kun imødegås – ikke fjernes helt.

Fremtiden er forudsigelighed

Hvis CPU-producenterne går tilbage til chips, som er deterministiske og forudsigelige, mindskes risikoen for disse såkaldte side channel-angreb. Det mener Jan Madsen, som er professor på DTU og ekspert i indlejrede systemer.

Forudsigelighed behøver ikke være forbundet med lavere ydelse, fortalte han tidligere på året til Version2:

»Der behøver ikke være et skisma. Når man taler om multikerne-arkitektur, så kan man blot have flere kerner og parallelisere softwaren. Vi er alligevel nået dertil i dag, hvor vi skal parallelisere software for at få højere ydelse. Jeg kan godt forestille mig, at disse spekulative elementer er noget, man genovervejer, også set i lyset og Spectre og Meltdown. Og om man ikke kan lave noget, som er meget mere forudsigeligt, men hvor man stadig har fuld ydelse ved at parallelisere.«

Indtil da kommer verdens computere og deres brugere til at leve med Meltdown, Spectre og deres fremtidige varianter.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (5)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Tobias Tobiasen

ét af computerhistoriens værste sikkerhedshuller kom til offentlighedens kendskab

Et sikkerhedshul hvor vi stadig har til gode at se det første udbredte angreb og hvor angriberen skal køre et program på offerets computer for at kunne lave privilege escalation... Det er ikke blandt de værste sikkerhedshuller i min bog. Der er talrige eksempler på remote code execution fejl der er langt være end spectra og meltdown.
I kan jo prøve at spørge Mærsk eller Equifax om de har eksempler på værre sikkerhedshuller...

Og JavaScript udnyttelsen (som vist i virkeligheden var WebAssembly) blev hurtigt fixet af browserne ved at gøre uret mindre nøjagtig.

Ditlev Petersen

Som jeg har fprstået det (altså ikke ret meget), så er angrebet mest lovende på maskiner, der kører programmer for andre. Altså noget med at køre sin snedige kode på en cloudmaskine eller lignende. En maskine hvor andet spændende kunne tænkes at køre, uanset at det kører i en helt anden virtuel maskine.

For det første behøver den slags ikke at blive opdaget. For det andet, hvordan angriber man egentlig en fremmed server, som man VED kører noget spændende? Det må være som at rende rundt i boligblok efter boligblok og lytte ved dørene, om nogen skulle nævne kontonumre i søvne. Bortset fra at man kan nå ret mange "boligblokke" på én nat.

Javascript-eksemplet er nok mindre spændende, men demonstrerede princippet.

Michael Cederberg

Et sikkerhedshul hvor vi stadig har til gode at se det første udbredte angreb og hvor angriberen skal køre et program på offerets computer for at kunne lave privilege escalation... Det er ikke blandt de værste sikkerhedshuller i min bog.

Det er en bombe under cloud tanken. Det kan ikke fikses nemt - problemet forsvinder først når milliarder af CPU'er er sendt på pension. Derfor er det seriøst. Og fordi det er fuldstændigt passivt så har vi ingen anelse om hvor udbredt det er.

Log ind eller Opret konto for at kommentere