Ett team av forskare från Vrije Universiteit Amsterdam har identifierat en ny (CVE-2020-0543) i de mikroarkitektoniska strukturerna hos Intel-processorer, anmärkningsvärt genom att det låter dig återställa resultatet av exekveringen av vissa instruktioner som körs på en annan CPU-kärna. Detta är den första sårbarheten i den spekulativa instruktionsexekveringsmekanismen som tillåter dataläckage mellan individuella CPU-kärnor (tidigare var läckor begränsade till olika trådar i samma kärna). Forskarna döpte problemet till CROSSTalk, men Sårbarheten kallas SRBDS (Special Register Buffer Data Sampling).
Sårbarheten avser för ett år sedan till klassen av MDS-problem (Microarchitectural Data Sampling) och är baserad på tillämpningen av sidokanalanalysmetoder på data i mikroarkitektoniska strukturer. CROSSTalk är nära sårbarhet , men skiljer sig i källan till läckan.
Den nya sårbarheten manipulerar läckan av en tidigare odokumenterad mellanbuffert som delas av alla CPU-kärnor.
är att vissa mikroprocessorinstruktioner, inklusive RDRAND, RDSEED och SGX EGETKEY, implementeras med den interna mikroarkitektoniska SRR-operationen (Special Register Reads). På berörda processorer deponeras data som returneras för SRR i en mellanbuffert som är gemensam för alla CPU-kärnor, varefter den överförs till en fyllningsbuffert associerad med den specifika fysiska CPU-kärnan på vilken läsoperationen initierades. Därefter kopieras värdet från fyllningsbufferten till register som är synliga för applikationer.
Storleken på den delade mellanbufferten motsvarar cache-raden, som vanligtvis är större än storleken på data som läses, och olika läsningar påverkar olika förskjutningar i bufferten. Eftersom den delade bufferten kopieras helt och hållet till fyllningsbufferten, flyttas inte bara den del som behövs för den aktuella operationen, utan även data som finns kvar från andra operationer, inklusive de som utförs på andra CPU-kärnor.
Om attacken lyckas kan en lokal användare autentiserad i systemet fastställa resultatet av att köra RDRAND-, RDSEED- och EGETKEY-instruktionerna i en främmande process eller inuti en Intel SGX-enklav, oavsett CPU-kärnan på vilken koden exekveras.
Forskare som identifierade problemet En prototypexploatering som demonstrerar förmågan att läcka information om slumpmässiga värden som erhållits genom RDRAND- och RDSEED-instruktionerna för att återställa en privat ECDSA-nyckel som bearbetats i Intel SGX-enklaven efter att endast ha utfört en digital signaturoperation på systemet.
problem ett brett utbud av stationära, mobila och server Intel-processorer, inklusive Core i3, i5, i7, i9, m3, Celeron (J, G och N-serien), Atom (C, E och X-serien), Xeon (E3, E5, E7-familjer, W och D), Xeon Scalable, etc. Det är anmärkningsvärt att Intel underrättades om sårbarheten i september 2018, och i juli 2019 tillhandahölls en exploateringsprototyp som demonstrerade dataläckage mellan CPU-kärnor, men utvecklingen av en fix försenades på grund av komplexiteten i implementeringen. Dagens föreslagna mikrokoduppdatering åtgärdar problemet genom att ändra beteendet för RDRAND-, RDSEED- och EGETKEY-instruktionerna för att skriva över data i den delade bufferten för att förhindra kvarvarande information från att lägga sig där. Dessutom pausas buffertåtkomst tills innehållet läses och skrivs om.
En bieffekt av denna typ av skydd är ökad latens vid exekvering av RDRAND, RDSEED och EGETKEY, och minskad genomströmning vid försök att exekvera dessa instruktioner samtidigt på olika logiska processorer. Att köra RDRAND, RDSEED och EGETKEY avbryter också minnesåtkomst från andra logiska processorer. Dessa funktioner kan påverka prestandan för vissa serverapplikationer negativt, så den fasta programvaran tillhandahåller en mekanism (RNGDS_MITG_DIS) för att inaktivera skyddet för RDRAND- och RDSEED-instruktioner som körs utanför Intel SGX-enklaven.
Källa: opennet.ru