Et team av forskere fra Vrije Universiteit Amsterdam har identifisert en ny (CVE-2020-0543) i de mikroarkitektoniske strukturene til Intel-prosessorer, bemerkelsesverdig ved at den lar deg gjenopprette resultatene av utførelsen av noen instruksjoner utført på en annen CPU-kjerne. Dette er den første sårbarheten i den spekulative instruksjonsutførelsesmekanismen som tillater datalekkasje mellom individuelle CPU-kjerner (tidligere var lekkasjer begrenset til forskjellige tråder i samme kjerne). Forskerne kalte problemet CROSSTalk, men Sårbarheten omtales som SRBDS (Special Register Buffer Data Sampling).
Sårbarheten gjelder et år siden til klassen av MDS (Microarchitectural Data Sampling) problemer og er basert på anvendelsen av side-kanal analysemetoder til data i mikroarkitektoniske strukturer. CROSSTalk er nær sårbarhet , men er forskjellig i kilden til lekkasjen.
Den nye sårbarheten manipulerer lekkasjen av en tidligere udokumentert mellombuffer som deles av alle CPU-kjerner.
er at noen mikroprosessorinstruksjoner, inkludert RDRAND, RDSEED og SGX EGETKEY, implementeres ved å bruke den interne mikroarkitektoniske SRR-operasjonen (Special Register Reads). På berørte prosessorer blir dataene som returneres for SRR deponert i en mellombuffer som er felles for alle CPU-kjerner, hvoretter den overføres til en fyllebuffer knyttet til den spesifikke fysiske CPU-kjernen som leseoperasjonen ble startet på. Deretter kopieres verdien fra fyllbufferen til registre som er synlige for applikasjoner.
Størrelsen på den mellomliggende delte bufferen tilsvarer cache-linjen, som vanligvis er større enn størrelsen på dataene som leses, og ulike lesninger påvirker ulike forskyvninger i bufferen. Siden den delte bufferen kopieres helt til fyllingsbufferen, flyttes ikke bare delen som trengs for den gjeldende operasjonen, men også dataene som gjenstår fra andre operasjoner, inkludert de som utføres på andre CPU-kjerner.
Hvis angrepet er vellykket, kan en lokal bruker som er autentisert i systemet bestemme resultatet av å utføre RDRAND-, RDSEED- og EGETKEY-instruksjonene i en fremmed prosess eller inne i en Intel SGX-enklave, uavhengig av CPU-kjernen som koden kjøres på.
Forskere som identifiserte problemet En prototypeutnyttelse som demonstrerer muligheten til å lekke informasjon om tilfeldige verdier oppnådd gjennom RDRAND- og RDSEED-instruksjonene for å gjenopprette en privat ECDSA-nøkkel behandlet i Intel SGX-enklaven etter å ha utført bare én digital signaturoperasjon på systemet.
problem et bredt utvalg av stasjonære, mobile og server Intel-prosessorer, inkludert Core i3, i5, i7, i9, m3, Celeron (J-, G- og N-serien), Atom (C-, E- og X-serien), Xeon (E3, E5, E7-familier, W og D), Xeon Scalable, etc. Det er bemerkelsesverdig at Intel ble varslet om sårbarheten i september 2018, og i juli 2019 ble det levert en utnyttelsesprototype som demonstrerte datalekkasje mellom CPU-kjerner, men utviklingen av en reparasjon ble forsinket på grunn av kompleksiteten i implementeringen. Dagens foreslåtte mikrokodeoppdatering løser problemet ved å endre oppførselen til RDRAND-, RDSEED- og EGETKEY-instruksjonene for å overskrive data i den delte bufferen for å forhindre gjenværende informasjon fra å sette seg der. I tillegg settes buffertilgang på pause til innholdet er lest og skrevet om.
En bieffekt av denne typen beskyttelse er økt ventetid når du kjører RDRAND, RDSEED og EGETKEY, og redusert gjennomstrømning når du prøver å utføre disse instruksjonene samtidig på forskjellige logiske prosessorer. Kjøring av RDRAND, RDSEED og EGETKEY suspenderer også minnetilgang fra andre logiske prosessorer. Disse funksjonene kan påvirke ytelsen til enkelte serverapplikasjoner negativt, så fastvaren gir en mekanisme (RNGDS_MITG_DIS) for å deaktivere beskyttelse for RDRAND- og RDSEED-instruksjoner som utføres utenfor Intel SGX-enklaven.
Kilde: opennet.ru