Ganske enkelt Intel har fortsatt å være målet for ulike sårbarheter som fører til datalekkasje og vi har snakket mye om dem her på bloggen Og i denne nye er Intel fortsatt ikke noe unntak.
Og det et team av forskere fra Free University of Amsterdam ha identifiserte en ny sårbarhet (CVE-2020-0543) i mikroarkitekturstrukturer av Intel-prosessorer, noe som er kjent for det faktum at lar deg gjenopprette resultatene av noen instruksjoner kjøres på en annen CPU-kjerne.
Dette er den første sårbarheten av mekanismen for spekulativ gjennomføring av instruksjoner, tillater datalekkasje mellom separate CPU-kjerner (Tidligere var lekkasjer begrenset til forskjellige tråder i en kjerne.)
Forskerne de kalte problemet CROSSTalk, men Intel-dokumenter refererer til sikkerhetsproblemet som SRBDS (Sample Special Register Buffer Data).
Om CROSSTalk
Sårbarheten tilhører klassen av MDS-problemer, introdusert for et år siden, og er basert på anvendelse av tredjeparts analysemetoder til data i mikroarkitekturstrukturer.
CROSSTalk-prinsippet er nær RIDL-sårbarhet, men er forskjellig i kilden til lekkasjen. Den nye sårbarheten manipulerer en mellomliggende bufferlekkasje tidligere papirløst som deles mellom alle CPU-kjerner.
Kjernen i problemet er at noen mikroprosessorinstruksjoner, inkludert RDRAND, RDSEED og SGX EGETKEY, er implementert ved bruk av SRR (Special Register Reads) intern mikroarkitekturoperasjon.
På sårbare prosessorer settes dataene som returneres for SRR i en mellombuffer som er felles for alle CPU-kjerner, hvoretter den overføres til populasjonsbufferen som er tilknyttet den spesifikke fysiske kjernen til CPU-en som oppstarten starter. Deretter kopieres verdien fra polstringsbufferen til registerene som er synlige for applikasjoner.
Størrelsen på den mellomliggende delte bufferen tilsvarer hurtigbufferlinjenAt er generelt større enn størrelsen på de avleste dataene og forskjellige leseoperasjoner påvirker forskjellige forskyvninger i bufferen.
Siden den delte bufferen kopieres til hele fyllingsbufferen, flyttes ikke bare den delen som kreves for den gjeldende operasjonen, men også gjenværende data fra andre operasjoner, inkludert de som er utført på andre CPU-kjerner.
Hvis angrepet er organisert vellykket, en lokal bruker autentisert på systemet kan bestemme resultatet utføre instruksjonene RDRAND, RDSEED og EGETKEY i en merkelig prosess eller i Intel SGX-enklave, uansett hvilken CPU-kjerne koden kjører på.
Forskerne som oppdaget problemet publiserte en utnyttelsesprototype som demonstrerte muligheten for å lekke informasjon på tilfeldige verdier oppnådd gjennom RDRAND- og RDSEED-instruksjonene for å gjenopprette ECDSA-privatnøkkelen som er behandlet i Intel SGX-enklaven etter at du bare har utført en digitalt signert operasjon på systemet.
Dette demonstrerte at et bredt utvalg av Intel stasjonære, mobile og serverprosessorer, inkludert Core i3, i5, i7, i9, m3, Celeron, Atom, Xeon, Scalable Xeon, etc., er sårbare.
Det er bemerkelsesverdig at Intel ble varslet om sårbarheten i september 2018 og i juli 2019 ble det gitt en prototype-utnyttelse som viste en datalekkasje mellom CPU-kjernene, men utviklingen av løsningen ble forsinket på grunn av kompleksiteten i implementeringen.
I dagens foreslåtte mikrokodeoppdatering, problemet blokkeres ved å endre oppførselen til instruksjonene RDRAND, RDSEED og EGETKEY for å overskrive dataene i den delte bufferen for å forhindre at gjenværende informasjon legger seg i den.
I tillegg gjelder suspensjon av buffertilgang til lese- og skriveoperasjoner er fullført.
En bivirkning av denne beskyttelsen er en økning i forsinkelser når RDRAND, RDSEED og EGETKEY utføres, og en reduksjon i ytelse når du prøver å utføre disse instruksjonene samtidig på forskjellige logiske prosessorer. Disse funksjonene kan påvirke ytelsen til noen applikasjoner negativt.
Fuente: https://www.vusec.net
Overskriften er ikke forstått, hvor tre punkter går, et komma skal gå, og, ja, at "ja" har en aksent.