Intels säkerhetsskydd CET 3.0 ska mildra sårbarheter i Tiger Lake

Om det här blir bra, så kan det bli som execution prevention - dvs, det gör utnyttjande av säkerhetshål mycket svårare i några år innan någon kommer på ett annat smart trick för att utnyttja dem. Återstår att se hur väl det fungerar, naturligtvis, men ansatsen är bra (och enkel nog för mig att förstå, vilket jag alltid gillar.)

Fast ROP är väl ändå ingen sårbarhet som läcker data,
ROP är en metod för att exekvera godtyckliga när din sårbarhet bara är en overflow som skriver över en pekare på stacken. Alla metoder i alla program slutar med att returnera, hoppar du till näst sista instruktionen med din stackpekare får du den och bara den utförd och det är trivialt att hitta en ROP för godtycklig instruktion.
Moderna datorer har väl haft Adress randomization ett tag så att man iaf inte kan förbereda en ROP-tabell i förväg för en viss version av program eller OS.

Vad är problemet med dessa säkerhetshål som vanlig användare idag om någon kan bistå med en update? Är det något som kan nyttjas via internet eller installerad programvara eller måste en duktig hacker fysiskt sitta bredvid min stationära dator/laptop?

Vad är riskerna idag efter ett antal patchar och silikonmitigeringar? antar att det är mycket svårare att nyttja idag än för 2 år sen?

Från nyheten:
”ROP är en metod för att läcka data som utvecklades som svar på”. Det anges alltså inte att ROP är en sårbarhet utan en metod.

Alltså va? På riktigt? Mjukvara för att upptäcka program som försöker attackera? Ska man ladda ner nya definitioner via Windows Defender kanske? Bara nej!

Sannolikt samma som alla andra säkerhetsbrister, att det krävs fysiskt åtkomst till datorn.

Önskar man kunde opt-out för sådana här säkerhetsfixar för att istället få maximerad prestanda, när man inte är direkt jätteutsatt i hemmet att någon spion från kreml ska besöka en och stoppa in en usb sticka i datorn.

Den här nyheten handlar inte om ett specifikt hål, utan om en metod som används för att utnyttja ett hål. Vad metoden gör är att detektera när någon försöker utnyttja en metod som ROP eller JOP och kraschar programmet om ett sådant försök upptäcks. Det är alltså ett sätt att förhindra att någon utnyttjar ett säkerhetshål som tillverkaren inte har upptäckt än.

Läs gärna den länkade PDFen för att förstå hur det fungerar. Summeringen i början är ganska lättfattlig.

Du kan göra det idag, samtliga sårbarhets mitigeringar kan du stänga av både under Windows och Linux. Windows är bara att gå under inställningsmenyn och söka på exploit tror jag så får du en meny där du kan klicka ur allt. Linux kan du ge en kernel parameter vid boot som jag inte minns men är ungefär "mitigatoin = off". blivit mer tillgängligt med en one-liner där.

Å tusan? Det kanske jag skulle googlat om det kommit. Jag trodde mer det var en drivrutin/bios fix som applicerats å sedan fick man leva med det. Var bara söka på exploit i settings som du sa. Tack!

Min CPU är å andra sidan från förra årtionedet (Snart härliga 12 år gammal!...) så det mesta är ändå inte applicerbart. Men då har jag något att googla på å se vad man kan stänga av där, tack!

Fast hur skulle just den här grejen ge sämre prestanda?

CET_SS borde inte påverka prestanda överhuvudtaget förutsatt att hårdvaruimplementationen är vettig. Använder man CET_SS istället för någon slags mjukvaruimplementation med stack canaries och grejer så borde det ge en positiv effekt på prestanda.

CET_IBT ger overhead i form av 4 bytes extra vid varje indirekt branch target i form av en endbr32/endbr64-instruktion vilket slösar lite cache o.s.v. men det borde i praktiken vara försumbart.

OK. Den här typen av allmänna mitigeringar, som denna och NX-biten, brukar inte döda prestandan. Man kan utveckla dem i lugn och ro och släpper dem inte förrän prestandan är god. När man är tvungen att pressa ut rena bugg-fixar, som för Spectre och Meltdown, så blir prestandan som den blir.

Som referens kan sägas att hela idén att dela upp stacken i två är gammal. Itanium hade två stackar i hårdvaran, till exempel. x86 har ju tyvärr inte det, men tanken att fixa till det på något sätt har funnits länge. Kompilatorn LLVM/Clang implementerar något som heter SafeStack sedan 2015, vilket åstadkommer något liknande Shadow Stack i ren mjukvara. Det är naturligt att implementera en sådan funktion i hårdvaran för att göra den ännu säkrare och snabbare, så det är bra att Intel gör det nu.

Med förbehållning att det krävs att programmet har matchande call- och ret-instruktioner vilket inte är garanterat. Om t.ex. så kallade retpolines eller andra esoteriska tillämpningar av ret eller call används så kommer det inte att fungera.

Samt att CET inte kan användas ihop med retpolines, men i praktiken spelar det ingen roll för det lär inte finnas någon CPU som har CET stöd men saknar enhanced IBRS (har man det slår då i alla fall inte Linux-kärnan på retpolines då de ger en prestandapåverkan).

Verkar som Intel har en ny bug i Ice Lake CPUer.
Saxat från: https://www.techpowerup.com/268479/intel-ice-lake-cpus-have-a-system-crashing-bug

"Thanks to community testing, we have found out that these issues are not just a software bug, however, it is a rather CPU specific bug that only occurs on Intel Ice Lake processors. Intel recently updated the CPU microcode and there is no improvement. It seems like the IntelliJ IDE has a specific sequence of instructions that trigger Ice Lake CPUs to crash OS."

@loevet Nåt som du har koll på?