Helt enkelt Intel har fortsatt att vara målet för olika sårbarheter som leder till dataläckage och vi har pratat mycket om dem här på bloggen Och i den här nya är Intel fortfarande inget undantag.
Och det ett team av forskare från Amsterdams fria universitet ha identifierade en ny sårbarhet (CVE-2020-0543) i mikroarkitekturstrukturer Intel-processorer, vilket är anmärkningsvärt för det faktum att låter dig återställa resultaten av några instruktioner kör på en annan CPU-kärna.
Detta är den första sårbarheten mekanismen för spekulativt genomförande av instruktioner, möjliggör dataläckage mellan separata CPU-kärnor (Tidigare var läckor begränsade till olika trådar i en kärna.)
Forskarna de kallade problemet CROSSTalk, men Intel-dokument hänvisar till sårbarheten som SRBDS (Sample Special Register Buffer Data).
Om CROSSTalk
Sårbarheten tillhör den klass av MDS-problem som introducerades för ett år sedan och baseras på tillämpningen av analysmetoder från tredje part till data i mikroarkitekturstrukturer.
CROSSTalk-principen är nära RIDL-sårbarhet, men skiljer sig åt i källan till läckan. Den nya sårbarheten manipulerar ett mellanliggande buffertläckage tidigare odokumenterad som delas mellan alla CPU-kärnor.
Kärnan i problemet är att vissa mikroprocessorinstruktioner, inklusive RDRAND, RDSEED och SGX EGETKEY, implementeras med den interna SRR-funktionen (Special Register Reads) mikroarkitektur.
På sårbara processorer placeras den data som returneras för SRR i en mellanbuffert som är gemensam för alla CPU-kärnor, varefter den överförs till befolkningsbufferten som är associerad med den specifika fysiska kärnan i den CPU där start startar. Därefter kopieras värdet från stoppningsbufferten till register som är synliga för applikationer.
Storleken på den delade mellanbufferten motsvarar cachelinjenAtt är i allmänhet större än storleken på den avlästa informationen och olika läsoperationer påverkar olika förskjutningar i bufferten.
Eftersom den delade bufferten kopieras till hela fyllningsbufferten flyttas inte bara den del som krävs för den aktuella operationen utan även återstående data från andra operationer, inklusive de som utförs på andra CPU-kärnor.
Om attacken organiseras framgångsrikt, en lokal användare autentiserad på systemet kan avgöra resultatet kör RDRAND, RDSEED och EGETKEY instruktionerna i en konstig process eller inom Intel SGX-enklaven, oavsett CPU-kärna körs koden.
Forskarna som upptäckte problemet publicerade en exploateringsprototyp som visade möjligheten att läcka information på slumpmässiga värden erhållna genom RDRAND- och RDSEED-instruktionerna för att återställa den privata nyckeln ECDSA som behandlats i Intel SGX-enklaven efter att endast en digital signerad operation har utförts på systemet.
Detta visade att ett brett utbud av Intel-stationära, mobila och serverprocessorer, inklusive Core i3, i5, i7, i9, m3, Celeron, Atom, Xeon, Scalable Xeon, etc., är sårbara.
Det är anmärkningsvärt att Intel underrättades om sårbarheten i september 2018 och en prototyputnyttjande tillhandahölls i juli 2019 som visade en dataläckage mellan CPU-kärnorna, men utvecklingen av lösningen försenades på grund av dess komplexitet.
I dagens föreslagna mikrokoduppdatering, problemet blockeras genom att instruktionernas beteende ändras RDRAND, RDSEED och EGETKEY för att skriva över data i den delade bufferten för att förhindra att kvarvarande information hamnar i den.
Dessutom gäller buffertåtkomstavstängning tills läs- och skrivåtgärderna är slutförda.
En biverkning av detta skydd är en ökning av förseningar när RDRAND, RDSEED och EGETKEY körs, och en minskning av prestanda när man försöker utföra dessa instruktioner samtidigt på olika logiska processorer. Dessa funktioner kan påverka prestandan för vissa applikationer negativt.
Fuente: https://www.vusec.net
Rubriken förstås inte, där tre punkter går, ska ett komma gå, och ja, att "ja" har en accent.