Nytt Spectre-liknande säkerhetshål upptäckt i Intels processorer

Oftast nyttjar man inte EN säkerhetsbrist utan en kombination. Du kanske förgiftar DNS register för att få någon att ladda ner en fil de tror är safe ifrån en server du kontrollerar som de sedan kör. De kanske använder en brist i Windows eller konfigureringen av miljön för at kunna exekvera mjukvara på datorn som sedan akn använda denna säkerhetsbrist för att komma åt kännslig data osv.

De testade något på AMD (A6-4455M Bulldozer) och något på ARM ( Kryo 280 ARMv8-A) och verkar inte ha lyckats.
"While the leakage exists on all Intel Core processors starting from the first generation, the timing effect is higher for the more recent generations with a bigger store buffer size. The analyzed ARM and AMD processors do not show similar behaviour"

Du tror inte "bad guys" sitte roch letar brister i mjuk- och hårdvara varje dag? De hade lika gärna kunnat vara de som hittade detta och sedan hållit det för sig själva och nyttjat bristen till att stjäla data utan att någon visste om det.
Det är en katt och råtta lek där man hela tiden försöker ligga steget före de som vill skada och identifiera säkerhetshål och ge tillverkarna möjligheten att täppa till dem innan felet skett.

Att inte prata om bristerna gör inte att de inte finns.

Det är lite som att skapa en webapp som hanterar viktig kunddata och sedan i den ha en sida som ger full tillgång till hela ens system för att "lättare kunna administrera" men lägga den på en adress som "bara jag känner till" och tro att det är säkerhet. Nej, en sådan bakdörr skall ALDRIG existera.

Obfuscation is not security.

Känns som att jakten på högre IPC har fått lämna plats för säkerheten.

Idag är praxis att bolag som berörs av säkerhetshålen meddelas i god tid innan något publiceras offentligt och om jag förstod rätt så har det även skett vid upptäckten av denna brist. Nästa steg är att offentliggöra bristen så bolag som använder sig av berörda produkter kan vidtaga åtgärder för att stänga ner eller minimera risken att utnyttjas.

Problemet med denna brist är att den funnits så länge och det går nästan omöjligen att säga om den redan utnyttjas därav i mitt tycke bör detta offentliggöras så snart det är möjligt.

Ännu ett i raden av orsaker att fundera på alternativ till x86...
Är man intresserad av modern CPU-design: läs rapporten, den beskriver saker som "store buffer" på ett relativt lättsmält sätt.

Vad rapporten lite missar är att beskriva varför Intel (och är väldigt nära 100 % säker att Zen har samma optimering, men tyvärr är både AMD och Intel allt mindre benägna att beskriva sina CPU på den detaljnivå man tidigare gjort, så går inte att säga med säkerhet) lagt så mycket kisel på ett så pass specifikt problem.

Tar man ett steg tillbaka börjar man nog rätt snabbt undra varför det man nästan slagit knut på sig själv att optimera ens är något man överhuvudtaget borde behöva bry sig om. Och däri ligger orsaken till varför detta inte är ett problem på ARM (och PowerPC, MIPS, RISC-V m.fl.): där var man nykter när man bestämde sig för vilka garantier en CPU bör göra kring ordning mellan läsning resp. skrivning from RAM i frånvaro av explicit synkronisering.

På en x86 garanterar att om tråd skriver till adress A, följt av en skrivning till adress B medan en annan tråd läser adress B, för att sedan läsa adress A så måste den läsande tråden se det "nya" data på adress A om den såg det nya som skrevs på B.

Tja, låter rätt logiskt? Ja, om man är en människa och vill resonera på ett väldigt sekventiellt sätt så är det "logiskt". Att man valde att garantera detta för x86 beror nog på att beslutet togs när RAM fortfarande vara väldigt snabbt i förhållande till CPUer samt framförallt att man gjorde det innan multi-core CPUer blev standard. Det är en rätt korkad design i praktiken då det hindrar en lång rad optimeringar i kisel och i samma stund CPUer fick fler än en CPU-tråd krävde ändå mer explicit synkronisering i de fall där olika CPU-trådar behöver kommunicera.

Problemet som beskrivs i den här sårbarheten finns inte ens på x86 om man har explicit synkronisering (då detta explicit säger att programmet kräver en viss ordning mellan minnesoperationer före och efter synkroniseringspunkten, så går inte att spekulera över den punkten vilket är ett krav för trigga "problemet"). Men i fallet ARM så triggas inte problemet i oavsett då ett krav är att en spekulation av en läsning måste gå "fel", vilket på x86 händer om man spekulativt läst A (det kanske redan låg i cache) för att sedan läst B (trots att de stod i omvänd ordning i programmet, i 999 fall av 1000 spelar det noll roll att ordningen ändrats, i det sista fallet behövs i praktiken explicit synkroniseringen om man vill följa standarden i ISO C/C++ resp. Java/C# språkstandarder, detta då de faktiskt stödjer annat än x86).

Så problemet finns inte på ARM då den inte behöver göra "roll-back" då den inte kan spekulera "fel". Problemet finns inte heller på x86 som saknar optimering för att ändå göra spekulativ läsning, det med kisellogik för att alltid ge illusionen till alla program att läsningar ändå gjordes i ordning. Grejen är att ju snabbare en CPU blir, ju mer vinner man på att tidigarelägga läsningar så långt det går (samt senarelägga skrivningar så långt det går, men inte lika viktigt att kunna byta ordning vid skrivning, vad man gör i praktiken är att ha en relativt lång kö för _alla_ skrivning, s.k. store-buffer). Är därför detta är en relativt ny optimering på x86 (ARM och PowerPC har gjort spekulativ läsning sedan urminnes tider då det inte kräver massa extra kisel).

Sårbarheten, "SPOILER"
Om jag förstår forskningsrapporten korrekt kan inte SPOLER själv användas till att stjäla information som t.ex. lösenord. Vad sårbarheten gör här att ge tillgång till meta-information som gör att andra redan kända attacker blir lättare att genomföra.

Sedan slirar man lite på sanningen när man säger att SPOILER kan utföras i en webbläsare. I teorin är det sant, i praktiken kräver det stöd för endera extremt noggranna timers alternativt tillgång till delat minne mellan webbworker trådar. Båda de senare är funktioner som stängs av som standard i aktuella webbläsare då dessa finesser även var ett problem för Spectre variant 1.

Och även om man kör en äldre webbläsare är SPOILER som sagt bara steg ett i en flerstegsraket. Den attack man flera gånger kommer tillbaka till är Rowhammer, en attack som i teorin är möjlig från JavaScript (i alla fall med s.k. webassembly) men som i praktiken ändå inte fungerar då dagens webbläsare har lagt ett extra lager mellan JS-motorns syn på minne och "native" kodens syn på minne.

Den som ska utföra en attack med SPOILER måste därför i praktiken kunna köra "native-kod" (C/C++ eller liknande som kompileras till maskinkod) på maskinen som ska attackeras. Fortfarande en sårbarhet då detta gör att en "vanlig" användare kan potentiellt få tag i information som ska kräva högre rättighetsnivå. Men det betyder i praktiken: du måste redan ha malware/virus på datorn innan detta kan utnyttjas, finns långt enklare metoder i det läget.

Värt att notera är att forskarteamet bara lyckades köra en fungerande proof-of-concept på en delmängd av Intel-systemen. Alla från Nehalem och framåt var mottagliga för SPOILER. Men SPOILER är som sagt bara steg ett i en flerstegsraket (två steg i deras PoC) och som steg två använde man Rowhammer. Initialt trodde man DDR4 var immun mot Rowhammer, men visade sig att följer man enbart JEDEC är det fortfarande möjligt att använda den attacken. I deras test lyckades man dock inte få till en fungerande Rowhammer attack på något av systemen som körde DDR4...

Finns säkert andra steg två man kan utnyttja, frågan är bara om det finns några vettiga sådan just nu då forskarna inte valde att testa något annat trots att PoC misslyckades på alla DDR4 system.

Risk vs kostnad
Är självklart superviktigt att det sker forskning på den här typen av svagheter, i vissa lägen kan det vara kritiskt.

Men man måste ha i bakhuvudet att för forskarnas finns en självändamål att måla upp just in upptäckt som väldigt allvarlig, det ger mer uppmärksamhet och i förlängningen mer forskningspengar.

Här är Spectre/Meltdown ett väldigt bra exempel. När dessa lanserades fick de extrem uppmärksamhet. Rapporterna innehöll fungerande PoC. Framförallt Meltdown målades upp som en smärre katastrof.

Nu, 14 månader senare, lär vi ju därför ha sett tusentals med malware/virus som använder sig av Spectre/Meltdown? Senaste noteringen jag sett är att vi fortfarande står på exakt noll försök att utnyttja dessa svagheter av faktisk malware/virus.

Hur kommer det sig?

Till att börja med är det Spectre variant 1 som seglat upp som den riktigt svettiga svagheten. För oss konsumenter är den enda realistiska attackvektorn webbläsaren, där har man bra skydd i programvara. Problemet med Spectre variant 1 är att ingen har ens en idé hur den ska patchas i HW och skydd i programvara kostar tid, pengar och prestanda.

Meltdown/spectre variant 2 är i praktiken värdelösa attackvektorer om man inte har möjlighet att köra valfri programvara på det lokala systemet (åter igen, räcker att köra som "vanlig" användare, men dock ska man ha den möjligheten). Dessa två är dock ett reellt problem i molntjänster där man kör egen programvara, är inte ett direkt problem om man bara nyttjar en service och därmed inte kan köra egen programvara (så ett icke-problem på de flesta "vanliga" servers).

Så orsaken till att ingen bryr sig om att använda dessa är samma som få inbrottstjuvar väljer att gräva sig ned under ditt hus för att ta sig genom golvet. Även om det är teknisk möjligt finns det massor med långt enklare sätt!

För Spectre/Meltdown tycker jag man kan säga att så här långt har kostnaden för att skydda sig varit orimlig i förhållande till vilken risk man utsätter sig för utan skydd, det undantaget just fallet med vissa molntjänster. Kanske därför inte så konstigt att alla större OS numera har standardfunktioner för att stänga av dessa skydd (Spectre variant 1 vill man dock INTE stänga av, tror inte heller det går att ta bort det i de stora webbläsarna).

@Yoshman:
"Så orsaken till att ingen bryr sig om att använda dessa är samma som få inbrottstjuvar väljer att gräva sig ned under ditt hus för att ta sig genom golvet. Även om det är teknisk möjligt finns det massor med långt enklare sätt!"

Typ; klicka på exefilen, för att se de glada grisarna dansa och sjunga.

Säkerhetshål? Folk har nog missuppfattat det hela. Alla dessa "hål" är bara inbyggda bakdörrar för diverse säkerhetstjänster...