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

Permalänk
Melding Plague

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

Den nya säkerhetstekniken sjösätts först i Tiger Lake och använder mjukvara för att mota sårbarheter som Spectre och Meltdown.

Läs hela artikeln här

Visa signatur

Observera att samma trivselregler gäller i kommentarstrådarna som i övriga forumet och att brott mot dessa kan leda till avstängning. Kontakta redaktionen om du vill uppmärksamma fel i artikeln eller framföra andra synpunkter.

Permalänk
Medlem

Säkerhetshål upptäckt i CET 3.0 om 3...2...1...

Permalänk
Medlem

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.)

Visa signatur

5900X | 6700XT

Permalänk
Medlem

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.

Permalänk
Medlem

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?

Permalänk
Lyxfällan 🎮
Skrivet av pacc:

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.

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.

Visa signatur

"We're with the press, hired geeks!"
Raoul Duke, Fear n' Loathing in Las Vegas

Permalänk
Medlem

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!

Permalänk
Medlem
Skrivet av Belgaar:

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?

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.

Permalänk
Medlem
Skrivet av Belgaar:

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?

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.

Visa signatur

5900X | 6700XT

Permalänk
Medlem
Skrivet av JBerger:

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.

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.

Visa signatur

Ryzen 5800x @ 32gb 3200mhz @ 7tb ssd @ 3060ti Fractal r5 @ Arch
i5 4670k @ 24gb 1600mhz @ Fractal r3 @ 12tb ZFS @ Truenas Scale
Thinkpad T450 @ i5 5300u @ 16gb @ 512gb ssd @ 24+48wh batteri @ Debian

Permalänk
Medlem
Skrivet av medbor:

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!

Nej, det funkar inte så. Jag vet inte hur mycket du vet om hur programmering fungerar på en assembler-nivå, men i korthet och starkt förenklat:

Om ett program anropar en metod - Call - måste det finnas ett sätt att gå tillbaka till den punkt man var i programmet. Metoden behöver inte veta var den anropades ifrån, den får bara indata som den skall bearbeta. Detta löses genom att man lagrar adressen man var i programmet på den s.k. stacken. Metoden som anropas gör vad den skall, och återgår sedan till programmet som anropade den genom att läsa den adressen från stacken - Return. Problemet uppstår i och med att man kan lagra alla möjliga saker på stacken. Dels lagrar man registrens innehåll när man gör anropet (så att metoden kan göra sina beräkningar utan att skriva över data som programmet som anropade den senare behöver), men man kan också manuellt lägga data på stacken, läsa ifrån den och rent allmänt manipulera den. Detta utnyttjas av angripare genom att helt enkelt ändra på adressen som man skall gå till för att sedan låta vänta på att programmet använder Return nästa gång. Vips har man tagit kontroll över programmet och kan styra vad som händer härnäst.

Intel's lösning här bygger på att man har en extra stack, kallad shadow stack, som endast innehåller adresser som man skall återgå till. När programmet försöker exekvera Return, kollar processorn av att adressen som man återgår till är samma som den i shadow stack. Är den inte det, kraschar programmet. Ergo fungerar inte return-oriented programming som en angrepps-metod längre.

Den andra delen av det här handlar om indirekta hopp, där programmet hoppar till en adress baserat på innehållet i ett register. Här är Intel's lösning att lägga in "flaggor" i koden för alla ställen man kan hoppa till. Efter ett indirekt hopp läser programmet nästa instruktion. Om det är en sådan flagga, så fortsätter programmet. Om det inte är det, så kraschar det.

Visa signatur

5900X | 6700XT

Permalänk
Medlem
Skrivet av sleepyoh:

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!

Permalänk
Medlem
Skrivet av JBerger:

Å 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?

Visa signatur

5900X | 6700XT

Permalänk
Medlem
Skrivet av mpat:

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

Det vet jag ej då jag inte läst djupare om den. Men annars har det ju varit standard att säkerhetshål i processorn har lett till försämrad prestanda efter en fix applicerats, så jag utgick från att samma gällde här.

Permalänk
Medlem
Skrivet av mpat:

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.

Visa signatur

Assembly är ett högnivåspråk.

Permalänk
Medlem
Skrivet av JBerger:

Det vet jag ej då jag inte läst djupare om den. Men annars har det ju varit standard att säkerhetshål i processorn har lett till försämrad prestanda efter en fix applicerats, så jag utgick från att samma gällde här.

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.

Visa signatur

5900X | 6700XT

Permalänk
Datavetare

Det inledande stycket i denna artikel är i sig inte fel, men tror den resulterar i att många missuppfattar vad det är CET faktiskt siktar in sig mot.

CET har absolut inget att göra med spekulering (mer än att man eventuellt kan utnyttja CET till att förenkla fixar för t.ex. vissa Spectre varianter).

CET 3.0 är en HW metod för att försvåra en klass av attacker som massor med gånger framgångsrikt används av olika former av malware.

Return/call-oriented-programming kan utnyttjas till att få ett program utför något helt annat än vad det är avsett att göra, även om det körs på en CPU som inte är mottaglig för någon av CPU-sårbarheterna runt spekulativ exekvering funderar tyvärr ändå Return/call-oriented-programming.

Vad Intel gör här är inte heller unikt, ARM har lagt till skydd mot ROP samt skydd mot COP, så det är inte heller specifikt för x86.

Skyddet mot ROP i CET 3.0 är i princip automatiskt, d.v.s. bara att slå på så omöjliggör de flesta av de former av ROP som man känner till idag. Skyddet mot COP kräver att man kompilerar om applikationerna, har CPUn CET 3.0 stöd blir det svårare att utföra COP medan programmet fortfarande fungerar på CPUer utan CET 3.0 stöd.

Så detta har inget med spekulering att göra och till skillnad mot spectre/meltdown/etc finns massor med kända fall där malware framgångsrikt använt ROP/COP. Ett problem för antivirus-program är ju att ROP/COP inte ändrar programmet, så väldigt lurigt att hitta dessa malware (men det går uppenbarligen).

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Yoshman:

Skyddet mot ROP i CET 3.0 är i princip automatiskt, d.v.s. bara att slå på så omöjliggör de flesta av de former av ROP som man känner till idag.

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.

Visa signatur

Assembly är ett högnivåspråk.

Permalänk
Datavetare
Skrivet av Gramner:

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).

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Lyxfällan 🎮

@Yoshman: Absolut, referenser till Spectre/Meltdown gjordes bara som en introduktion till Intels arbete mot sårbarheter, men jag ser också att det kan misstolkas som att de är kopplade till varandra. Justerade inledningen för att undvika missförståndet.

Visa signatur

"We're with the press, hired geeks!"
Raoul Duke, Fear n' Loathing in Las Vegas

Permalänk
Medlem

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å?