Forskere fra Bitdefender ny sårbarhet () i den spekulative instruksjonsutførelsesmekanismen til moderne CPUer, som heter SWAPGS, som tilsvarer navnet på prosessorinstruksjonen som forårsaker problemet. Sårbarhet la en uprivilegert angriper bestemme innholdet i kjerneminneområder eller kjører virtuelle maskiner. Problem i Intel-prosessorer (x86_64) og delvis AMD-prosessorer der hovedangrepsvektoren ikke vises. Tidligere implementerte metoder for å motvirke Spectre- og Meltdown-sårbarhetene beskytter ikke mot SWAPGS-angrepet ved bruk av Intel-prosessorer, men det er allerede foreslått reparasjoner for Linux, ChromeOS, Android og Windows.
Sårbarheten tilhører Spectre v1-klassen og er basert på ideen om å gjenopprette data fra prosessorcachen som er igjen etter spekulativ utførelse av instruksjoner. For å forbedre ytelsen bruker grenprediksjonsenheter av moderne CPU-er forebyggende utførelse av noen instruksjoner som mest sannsynlig vil bli utført, men uten å vente på beregningen av alle faktorene som bestemmer utføringen deres (for eksempel når grenbetingelser eller tilgangsparametere ikke har ennå blitt beregnet). Hvis forutsigelsen ikke bekreftes, forkaster prosessoren resultatet av den spekulative utførelsen, men dataene som behandles under den forblir i prosessorbufferen og kan gjenopprettes ved hjelp av metoder for å bestemme innholdet i hurtigbufferen gjennom sidekanaler, analysere endringen i tilgang tid til hurtigbufrede og ubufrede data.
Det særegne ved det nye angrepet er bruken av en lekkasje som oppstår under spekulativ utførelse av SWAPGS-instruksjonen, som brukes i operativsystemer for å erstatte verdien av GS-registeret når kontrollen går fra brukerplass til OS-kjernen (GS-en). verdien brukt i brukerområdet erstattes med verdien brukt under operasjoner i kjernen ). I Linux-kjernen lagrer GS en per_cpu-peker som brukes for å få tilgang til kjernedata, og brukerplass lagrer pekere til TLS (Thread Local Storage).
For å unngå å kalle SWAPGS-instruksjonen to ganger når du får tilgang til kjernen igjen fra kjerneplass eller når du kjører kode som ikke krever en GS-registerendring, utføres en sjekk og en betinget gren før instruksjonen. Den spekulative utførelsesmotoren fortsetter proaktivt med å kjøre kode med SWAPGS-instruksjonen uten å vente på resultatet av sjekken, og hvis den valgte grenen ikke bekreftes, forkaster den resultatet. Dermed kan det oppstå en situasjon når en gren som ikke involverer SWAPGS-kjøring er spekulativt valgt, men under spekulativ kjøring vil verdien av GS-registeret endres av SWAPGS-instruksjonen og brukes i avhengige minneoperasjoner som havner i CPU-cachen.
Forskere har foreslått to angrepsscenarier som det er utarbeidet utnyttelsesprototyper for. Det første scenariet er basert på situasjonen der SWAPGS-instruksjonen ikke utføres spekulativt, selv om den faktisk brukes i utførelse, og det andre er det motsatte, når SWAPGS-instruksjonen utføres spekulativt, selv om den egentlig ikke skal utføres. For hvert scenario er det to alternativer for utnyttelse: angriperen kan bestemme verdien på en bestemt adresse i kjerneområdet, og angriperen kan søke etter en bestemt verdi på tilfeldige adresser i kjernen. Å utføre et angrep tar lang tid og utnyttelsen kan ta flere timer for å fullføre lekkasjen.
Det er et problem i Linux-kjernen ved å endre logikken for å kalle SWAPGS-instruksjonen (blokkere spekulativ kjøring), på samme måte som korrigeringen av andre Spectre v1-klassesårbarheter. Den ekstra beskyttelsen forventes å ha minimal innvirkning på ytelsen til typiske arbeidsbelastninger. Latency oppstår under byttefasen mellom bruker- og kjerneplass, noe som kan resultere i dårlig ytelse når det for eksempel er tunge systemanrop fra applikasjonen eller hyppig generering av NMI-er og avbryter.
Reparasjonen krever installasjon av en kjerneoppdatering på både vertssystemet og gjestemiljøene, etterfulgt av en omstart av systemet. For å deaktivere beskyttelse på Linux, kan "nospectre_v1"-alternativet brukes, som også deaktiverer tiltak for å blokkere SWAPGS-sårbarheten. Reparasjonen er tilgjengelig som for Linux-kjernen, som allerede er inkludert i utgivelsene , , 4.14.137, 4.9.188 og 4.4.188. Oppdateringer for Linux-distribusjoner er ennå ikke utgitt (, , , , , ). På Windows ble problemet stille og rolig løst inn . Google Company fix for kjerne 4.19 levert med ChromeOS og .
Ifølge forskere fra Bitdefender ble Intel informert om problemet tilbake i august i fjor. Det ble besluttet å fikse problemet programmatisk, der utviklere fra Microsoft, Google og Linux-kjernen var involvert i den koordinerte utviklingen av en rettelse. Eldre Intel-prosessorer, pre-Ivy Bridge, er mye vanskeligere å angripe på grunn av mangelen på støtte for WRGSBASE-instruksjonen som brukes i utnyttelsen. ARM-, POWER-, SPARC-, MIPS- og RISC-V-systemer påvirkes ikke av problemet fordi de ikke støtter SWAPGS-instruksjonen.
Problemet rammer hovedsakelig eiere av Intel-prosessorer -
På AMD-systemer var bare det andre angrepsscenarioet i stand til å reproduseres, som er begrenset til spekulativ behandling av basisverdien til GS-registeret, som kan brukes til å se etter spesifikke verdier i tilfeldige minneområder. For å blokkere dette angrepsalternativet eksisterende metoder for beskyttelse mot Spectre v1.
Kilde: opennet.ru