Google och Microsoft upptäcker nytt säkerhetshål i processorer

Obligatorisk #detgårbranu

Snälla låt inte Microsoft programmera en patch räcker med bsod på kontoret sen meltdown...

Pratar du om microsofts "SBS-korrigeringar"?

Om man förstått det rätt så är det en väldigt gammal höna... men hon har inte lagt några ägg på 15 år+, så man har ignorerat riskerna. Mycket har ju hänt på bara 5 år när det gäller säkerhetstänkandet och risker, så när nu ett enda ägg lades 2017 med Spector och Meltdown.... har du ägg och kycklingar överallt nu.

Problemet är väl snarare att du inte kan stoppa epidemin utan att slakta kycklingar och krossa en massa ägg, med mycket negativa biverkningar som resultat.

"Till The Verge har Intel sagt att uppdateringen kan orsaka prestandatapp på två till åtta procent, varför skyddet är avstängt som standard." Huh?

Jaha så när fan kommer intel att ersätta min processor?

Är ett väldigt rationellt beslut i detta fall. Tack och lov att det finns någon gräns för hur mycket man dansar efter säkerhetsprimadonnornas pipa...

På vilken grund hävdar jag då detta?

För att det ens ska vara teoretiskt möjligt att utnyttja denna sårbarhet måste fyra saker vara uppfyllda

• det kontext, A, som ska stjäla information måste vara separerad från det kontext, B, informationen ska stjälas från på ett sätt så det normalt inte ska vara möjligt för A att läsa minnet hos B

• en läsning, L, måste följa en skrivning, S, där de två minnesoperationerna använder olika register att referera in i minne, vid körning måste de två minnesoperationerna referera samma adress eller åt i alla fall delvis överlappa

• beräkningen av adressen för S måste bli fördröjd, t.ex. cache-miss eller liknande, medan beräkningen av adressen för L är direkt tillgänglig (vilket åter igen kräver att adresserna ligger i olika register, är det samma register drabbas ju båda lika)

• det data som L erhåller måste användas till en påföljande minnesoperation, exakt var i cachen denna operation hamnar är det som ger den möjliga sidokanalen (vilket då implicit betyder att den som attackerar måste ha viss styrning över vilken adress L sker)

Hur vanligt är detta då att allt ovan är uppfyllt i verklig kod?

Microsoft har tittat på en hel i deras egna system och har så här långt hitta noll sådana fall. D.v.s. så vitt de vet är det inte ens teoretiskt möjligt att utnyttja svagheten i praktiken. Två stora orsaker här, dels är det rätt strikta krav och dels försöker kompilatorer (och programmerare som har någon känsla för att skriva effektiv kod) i det längsta undvika implicit aliasing av minnesaccesser. Kompilatorer kommer inte heller generera load/stores med olika register för minnesreferens när det är uppenbart att operationerna läser samma minne (eller samma baspekare med lite olika offset, men i det läget "ser" CPUn om det blir en RAW och undviker då att spekulera).

Faktum är att så här långt har man sett exakt noll försök till att utnyttja någon av de fyra svagheter som presenteras så här långt. OBS: man har alltså inte ens sett försök till att utnyttja dessa svagheter. Normalt ser man massor med försök att utnyttja svagheter, men många attacker stoppas i praktiken av olika skyddsnät (antivirus och liknande).

Varför?

Tja, vad är kraven på de övriga

• speculative execution bounds-check bypass: "Spectre variant 1", denna hade antagligen utnyttjas om inte webbläsarna patchas så snabbt. Av alla svagheter är detta den enda där det är sannolikt att en vanlig konsumentdator skulle attackeras, så självklart ska denna patchas (är som tur är relativt billigt prestandamässigt, tyvärr måste man patcha varje sårbar programvara då det inte går att föra en CPU-fix)

• branch target injection: "Spectre variant 2", detta påminner rätt mycket om det som nu upptäckts i att kravlistan på saker som måste vara uppfylld innan denna ens är teoretiskt möjligt att utnyttja är lång. Här krävs i praktiken till och med att man redan fått virus/malware på en normal desktop-maskin då saker som JavaScript-motorer hindrar attacken. Fixen för denna ger relativt stor prestandapåverkan i vissa fall, är också fixarna för denna som orsakat en rad stabilitetsproblem på Windows..

• rogue data cache load: "Meltdown", är fullt möjligt att utnyttja denna i praktiken på en server där flera virtuella instanser kör och där de som administrerar respektive virtuell instans inte litar på varandra (så där måste man självklart patcha!!!). Är i praktiken i det närmaste ofarlig på en typisk desktop-dator, precis som "Spectre variant 2" krävs att den som attackerar först får in virus på din dator innan det ens är teoretiskt möjligt att nyttja svagheten.

Argumentet har varit att spectre variant 2 och meltdown ändå är relevanta på desktop då de i teorin ger en attackvektor för ett virus (som redan måste finnas lokalt på systemet!) att bli root/admin. Helt sant, men det är långt ifrån enkelt att lyckas med det i praktiken och under 2017 upptäcktes i genomsnitt två "local privilege escalation" per vecka i Windows. Är väsentligt enklare att utnyttja dessa jämfört med att försöka med spectre variant 2 / meltdown.

Bilden över hur lätta dessa svagheter är att utnyttja är nog rejält felaktig. I praktiken är det svårt att utnyttja de flesta av dessa svagheter ens i proof-of-concept där man totalt kontrollerar både programvaran som ska attackeras (den är i PoC helt tillrättalagd) och programvaran som utför attacken. Både i variant 2 och 4 måste man matcha dessa två programvaror helt för det specifika fallet (d.v.s. HW-konfig, OS, etc.). Variant 2 visat sig vara extremt svårt att utnyttja ens i PoC.

Säkerhet är absolut viktigt, försöker absolut inte hävda att man ska skita i det (skulle aldrig köra viktiga saker i "molnet" på en server som inte är säkrad mot meltdown). Men får finnas någon balans mellan risk och tillfört värde.

Rätt många åkte nog bil till jobbet i morse. Det trots att lite fler än två människor dör p.g.a. trafikolyckor per minut. Värdet att utsätta sig för den risken överväger för de flesta vida risken att förolyckas. För datorer är det egentligen ännu lättare att bedöma risk/värde: så länge jag vinner mer på att ta en risk jämfört med genomsnittskostnaden för problemen är det rationellt att ta risken!