Allvarligt säkerhetshål upptäckt i Intels processorer

Spännande!

Läste på andra forum att säkerhetshålet är riktigt allvarligt med...
https://www.wired.com/story/critical-intel-flaw-breaks-basic-...

Påverkar även AMD och ARM enligt artikeln.

Så gott som alla Intel-processorer sedan 1995,
Mer information: https://spectreattack.com/

Jag är tveksam till att säkerhetshålen är så stora under windows. För under windows gäller, kör man något exekveringsbart applikation som en ondskefull person har gjort så är man körd, detta oavsett om buggarna ovanför fanns eller ej.
Så man ska ej köra applikationer vars tillverkaren man ej litar stenhårt på och installationsfilerna kommer raka vägen ifrån dessa.

Att någon från ett annat VM kommer åt ett annat VM data är ett jätteproblem i Molnet, men alla kör inte alla maskiner där.

Att folk surfar in på skumma sidor, så ska man ej göra detta. Tar vi windows servrer 2012 R2, så kan man inte ens besöka www.microsoft.com utan att rejält sänka webbläsarens säkerhetskrav, lägga in undantag för sidan och typ bocka i en ruta som säger. -Du vet om att du är en vårdslös idiot som tillåter webbläsaren besöka denna sida?

Så kvar är attacker utifrån och detta är väl inget problem med hålen ovanför?

*edit*
Tar man en server som många delar på, så brukar det för användare vara program som körs i kiosk mode. För utvecklare så gäller snarare är det någon ondskefull så är servern förlorad. -Det är därför de brukar ha 10års krav på erfarenhet, så man har visat sin godhet under denna tid.

Någon annan som fått maintenance notice från Azure?

Dom säger att uppgraderingen knappt kommer märkas prestandamässigt. I samma mening skriver dom även "We've worked to optimize the CPU and disk I/O path and are not seeing noticable performance impact after the fix has been applied"

Skulle allt vilja veta mer i detalj.

Dessa två payload exploits, hur kan de användas. Meltdown verkar vara kraftfullare men kan patchas. Spectre, kan även denna exploit skrivas med JavaScript? Räcker de att patcha OS och rensa cachen i CPUn eller är patchen verkligen bar för meltdown?

Skickades från m.sweclockers.com

Patchen är för Meltdown. För Spectre handlar det om att minska skadeverkningarna i program som kör kod som man inte kan lita på. Det finns en sådan patch på gång för Chrome, inte hört något om övriga webbläsare.

Då är de ju riktigt allvarligt. Man blir ju lätt paranoid. Skapa en reklam på Aftonbladet med Spectre payload I JavaScript och har du tur kan du fiska upp inloggningsuppgifter till Gmail eller liknande.

Så stänga ner alla flikar när man loggar in någonstans om man vill vara på den säkra sidan?

Skickades från m.sweclockers.com

För ESXi från VMware:
https://blogs.vmware.com/security/2018/01/vmsa-2018-0002.html
Spectre gör de möjligt för virtuella maskiner att läsa minnet från andra virtuella maskiner. Meltdown kan inte användas för att attackera hypervisor eller andra VM. Om jag förstått de rätt dvs.

Skickades från m.sweclockers.com

Ja, det är riktigt. Vad du kan göra är att skapa en array, och sedan läsa lite efter att den slutar. För att det skall vara effektivt måste du veta vad som ligger precis efter din array i minnet. Om jag förstår koden rätt kan du läsa ganska långt efter din array, men du måste veta hur allt ligger till i minnet för att du skall få ut något relevant. Hela koden bygger på att man tränar branch predictorn att hela tiden gissa att din if-sats är sann. Läsningen bygger på att predictorn gör fel - den läser en gång när den inte borde, och du kan se vad den läste. Så fort du har läst fel en gång, börjar predictorn lära sig att den inte alltid skall anta att if-satsen är sann. Kan du läsa två gånger? Kanske. Tre? Kanske inte - branch predictors är smarta, de kommer att fatta att svaret beror på hur stort det där X-värdet är.

Om du läser en byte åt gången, måste målet vara en array som är 64KB - klart möjligt. Två bytes, och det är en array på 16 MB. Tre, och arrayen blir 4GB. Större går rimligen inte. Man kan alltså läsa två eller tre bytes ett par gånger - då måste man veta precis var hemligheten ligger i minnet, man kan inte bara fiska.

https://googleprojectzero.blogspot.se/2018/01/reading-privile...
Enligt P0 så kan man läsa 2000kB/s efter en upstartssträcka av 4 sekunder. Om man siktar in sig på en applikation borde man väll kunna hitta något spännande på 2kB/s? Tänker på PoC nr2 av variant 1.
Har jag fattat de rätt att Spectre går ut på att CPUn laddar in minnet (RAM) utanför programmets adressrymd genom att lura CPUn att ladda minne den tror att den kommer behöva framöver? Så genom att lura predictorn som du skrev.

Skickades från m.sweclockers.com

Chrome skall isolera olika flikar från varandra i olika processer, vilket borde göra Spectre svår att genomföra på det sättet, men ta du det säkra före det osäkra. Det här är fortfarande nytt, och vi säkert några otrevliga överraskningar de närmaste månaderna.

Det där är mer än jag trodde, 2KB per sekund är ju en del. Man märker nog om en webbsida helt plötsligt börjar använda all CPU, dock.

Ja, i princip går det till som du säger. Predictorn tror att en läsoperation skall göras, och gör den i förväg. När det blir klart att predictorn har fel så backar den läsningen, men då kan man genom cache-analys se vad den har läst, vilket läcker adressen den läste från.

Och du säger att artikeln här har satt sig in i problematiken med hur det påverkar oss användare?
Eller att användare här på forumet vet lika mycket som It-tekniker som hanterar Google och Amazon servrarna?

Läser jag första sidan av kommentarer är det som vanligt pajkastning mellan intel/amd, hur dåliga intel är och sen massa annat som är helt irrelevant för mig som användare att förhindra att jag som användare drabbas av detta säkerhetshål.
Fria Tider lyfter i sin artikel det som användare i kommentarsfältet här skriver, som att CEO sålt aktier, och inte förrän på sida två så nämns något vettigt som Javascript och att detta säkerhetshål kan missbrukas där.
Att sen komma med FUD om att stänga av internet är ju inte heller hjälpsamt så frågan är vem som tramsar bort problem!

Sen tar vi detta inlägg:

Sen kommer flera inlägg efter och fördömer inlägget som helt värdelöst:
"We don’t know how attackers exploit the hardware bug in Intel and apparently ARM CPUs yet. All we know is that it’s apparently possible to discern the contents of protected kernel memory by leveraging this exploit. There may be some conceptual similarities to Rowhammer, the DDR memory attack technique that we’ve discussed before, in how this attack is carried out. Rowhammer can be used to change the data stored in certain memory locations by “hammering” adjacent rows of DRAM until the electrical charge in the target cells flips."

Vad har detta med 50% sämre prestanda, det är väl inte det viktiga här(för mig iaf), utan hur jag som användare kan undvika att någon utnyttjar denna bugg på min dator.
Men jakten på mer prestanda är viktigare än säkerhet och stabilitet... det är det man ser på inläggen här, lite märkligt när artikeln nämner ett allvarligt säkerhetshål!

Ännu ett exempel på inlägg utan alla kort och fakta på bordet

https://www.sweclockers.com/nyhet/24985-amd-intel-och-arm-sva...

Så de är "bara" adressen som man får fram i de steget? Måste man inte använda sig av någon annan exploit för att komma åt den faktiska data då?

Tanke:
De är därför man vill ladda funktionen av de man vill attackera så man får en adressrymd man faktiskt är intresserad av. Försökte förstå mig på JavaScript PoC från GitHub men fattade aldrig varför den försökte exekviera funktionen från de program den ville attackera. Detta betyder ju dock att de inte kommer vara enkelt att utnyttja denna exploit endast, de behövs fler verktyg för att komma åt data.

Skickades från m.sweclockers.com

Nej, det hade han ju inte om han svarade igår, men inlägget råkar vara korrekt. Meltdown påverkar endast Intel, och patchen som skäl prestanda är för Meltdown, så då knappar ju AMD in lite om man vill se det så. Sen är bägge utsatta för Spectre (även om AMD indikerar att Zen klarar sig bättre även där), men där kommer skademinimeringen att ske på applikationsnivå och drabba alla lika mycket. Inte klart hur mycket den ändringen skadar prestanda.

Det är detta som är så intelligent. Man gör en array1 som är säg 100 byte lång, och ligger precis innan den data man vill komma åt. Säg att det hemliga värdet är 47, och ligger i byten precis efter array1. Sedan gör man en massiv array2, som ligger var som helst, och gör en kod som

if(x<size_of_array)
y=array2[array1[x]*256]

size_of_array är alltså 100 här.

Sen ser man till att array2 inte ligger i cachen, och så kör man koden ovan en massa gånger med ett x som är mindre än size_of_array, så att predictorn lär sig att detta if alltid skall vara sant. Sedan kör man det en gång med ett x som är för stort - det är 101 i det här fallet. Predictorn kommer då att anta att villkoret är sant igen, och köra laddningen nedan fast den inte borde. Den tittar på värdet precis efter array1, och använder detta för att läsa i array2. Angriparen kan då titta på vilket värde i array 2 som kommer tillbaka snabbt. Värde nummer 47 kommer att komma tillbaka mycket snabbare, vilket gör att angriparen vet att det hemliga värdet är 47.

(Att man multiplicerar med 256 beror på att det är längden på en rad i cachen. Man måste ha värdena på olika rader i cachen för att kunna se vilket värde som lästs tidigare)

Det är riktigt, den här tekniken är bara ett verktyg av flera. Den gör ingenting själv, utan är att jämföra med en buffer overflow eller så.