"Take a Way" - säkerhetshål i AMD-processorer

@evil penguin: Kan säga att AMDs svar verkar rätt märkligt, det är INTE så att denna sårbarhet försvinner om man slår på fixarna för tidigare svagheter som drabbar AMDs CPUer.

Spectre utnyttjar ju egenheter i spekulativ exekvering och branch-predictor. Detta är, likt Zombie Load, en attack som utnyttjar att data som träffar L1D$ blir tillgänglig för CPU snabbare än data som inte ligger i L1D$.

En orsak att Zen inte drabbades av SMT specifika MDS buggar är att man taggat minnesoperationer med tråd ID. Så man kan inte från tråd #0 få tag i sådant som tråd #1 på samma fysiska kärna precis läs/skrivit.

Så man är safe? Nej!

Implikationen av "skyddet" ovan gör att man från tråd #0 kan tvinga ut en viss cache-line från L1D$ till L2$. Om tråd #1 läser eller skriver en minnesadress som råkar mappa till både samma cache-set och samma cache-way så har man en attack. På Intels Core fungerar inte den attacken då val av cache-way i praktiken är slumpmässigt, det har fördelen att ge lite bättre utnyttjandegrad av cache men nackdelen att uppslagning drar mer ström då man måste kolla ett visst cache-set i alla cache-ways (8 st för dagens "big-core" X86 i L1D$).

AMD har ett patent på algoritmen att "gissa" rätt cache-way givet den virtuella adressen. Det forskarna gjorde var att lura ut hur den mappningen fungerade, m.h.a. har man nu ett sätt att få meta-information om vad tråd #0 nyligen läst/skrivit från tråd #1. Det även fast trådarna kör i olika processer och därmed borde vara helt isolerade.

Det som är en förmildrande omständighet är: fungerar bara om SMT är aktiverat och man får bara meta-information, inte direkt information om vilken data som läst/skrivit.

Detta är väldigt likt Spectre variant 1, om data används för indexera i en array kan man därifrån räkna baklänges och därmed lura ut faktisk data. Inte möjligt i det generella fallet, men tyvärr inte helt osannolikt vid just kryptering (den PoC som forskarna gjort, men inte publicerat då AMD inte get ut något patch än, användes just för att extrahera krypteringsnycklar).

Den uppenbart förvärrande egenskapen är hur pass lätt det var att svänga ihop en fungerande PoC på min 3900X givet denna information. Har lyckats kört vissa av de PoC som finns för Intel, men där har det varit nära nog ett krav att man stänger av "turbo-boost" för att ska fungera. Gjorde initialt därför det direkt på 3900X, men givet hur denna sårbarhet fungerar är det inte kritiskt att hålla en helt stabil CPU-frekvens. Det är helt enkelt så pass stor skillnad mellan träff i L1D$ (~4 cykler) och miss att man "tål" rätt stor varians.

Det skrivet: är ändå inte speciellt oroad. De vanliga hopplösa förutsättning krävs: d.v.s man måste säkerställa att attackerande tråd är låst till samma fysiska kärna, men den andra CPU-tråden, som det man attackerar. Den man attackerar måste också nästan konsekvent läsa/skriva det data man vill stjäla (det gäller i princip av svagheterna av den här typen, framförallt MDS som bara drabbar Intel). Man måste vara "root" (admin på Windows) för att låsa en process man inte själv äger till en viss CPU-tråd!

Men AMDs svar är som sagt rätt märkligt, läser man rapporten borde det vara uppenbart för i alla fall vissa av deras ingenjörer att existerande motmedel inte hjälper. Eller, inte helt sant. Jag gjorde en PoC för det som kallas "Load+Reload", den andra som kallas "Collide+Probe" borde vara omöjlig på ett system som har fixen för Meltdown. Den fixen ser till att kärnans adressrymd inte är mappad när man är i userland, kostar prestanda men redan innan Meltdown jobbade man på den patchen då den ger bättre säkerhet i flera lägen (tror MacOS kör på det sättet väldigt länge).

Tänker inte posta källkoden, i alla fall inte innan det finns en patch. Har inte trimmat in den speciellt mycket så den är inte 100 %-ig. Men tillräckligt för att visa att buggen finns.

Det som skrivs ut som "V: _" är var min "victim process" läser för data.
Det som skrivs ut som "Letter is: _" är vad mitt attackprogram tror att den läste. Båda kör som separata processer, låst till en varsin tråd på samma fysiska kärna.

V: x
Letter is: 8
Letter is: 8
Letter is: x
Letter is: x
Letter is: 8
Letter is: x
Letter is: x
Letter is: x
V: y
Letter is: y
Letter is: 9
Letter is: y
Letter is: 9
Letter is: y
Letter is: y
Letter is: y
Letter is: y
V: z
Letter is: 9
Letter is: z
Letter is: :
Letter is: :
Letter is: z
Letter is: z
Letter is: :
Letter is: z
Done

Kör man samma program på Intel är det helt slumpmässigt information som skrivs av attackerande process.''

kjonsson@ryzen:~/programming/c/takeaway/build$ (taskset -c 0 ./victim Hej &); taskset -c 12 ./attacker 
V: H
Letter is: c
Letter is: H
Letter is: H
Letter is: H
Letter is: H
Letter is: H
Letter is: H
Letter is: H
V: e
Letter is: e
Letter is: e
Letter is: e
Letter is: e
Letter is: e
Letter is: e
Letter is: e
Letter is: e
V: j
Letter is: e
Letter is: j
Letter is: j
Letter is: j
Letter is: j
Letter is: j
Letter is: j
Letter is: j
Done

Tror vi kommer se mer av dessa säkerhets luckor båda från AMD och Intel framöver, läggs ju onekligen mycket forskning på området. Är det någon speciella anledning att alla nyheter kretsar kring Intel när de finns problem på båda sidor?

Eftersom Intel är dominerande på marknaden (inte bara sälj utan aktiva burkar i huvudsak) så är det mer logiskt att rikta in sig där. I takt med att AMD plockar andelar och kommer ut mer på marknaden kommer vi garanterat se mer

@Dumbullen: Ja att de är mer fokus på Intel är förståeligt men de gör ju inte problemen mindre viktiga att belysa. Eftersom att AMD plockar mer mark för varje månad så borde ju de vara minst lika viktigt att rapportera om problemen som uppenbarligen finns.

Ingen jobbar gratis är nog den enkla sanningen. Fler Intel-system = mer finansiella incitament
Samma anledning som att Apple länge kunde skryta med att MacOS inte hade virus, det har inte att göra med att det är ett magiskt OS. Bara ingen som brydde sig

Edit: för att förtydliga så handlar det inte om att t.ex SweC inte rapporterar om det. Bara att inte lika många forskare letar sårbarheter

Verkar uppblåst.

https://www.tomshardware.com/news/new-amd-side-channel-attack...

Spectre, framförallt variant 1, är den klart värsta av alla sårbarheter som hittats så här långt. Både i hur den kan utnyttjas (går via webbläsaren om de saknar skydd för spectre) och p.g.a. att denna drabbar i princip alla moderna högpresterande CPUer, Intel, AMD, ARM (både ARM och Apple) och IBM(PowerPC).

Finns både förmildrande omständigheter jämfört med MDS i Take A Way, det är just att man läcker meta-data och inte faktisk data. Vad det betyder är att man måste hitta en s.k. gadget, en kodsnutt som använder data man vill läsa i någon form av minnesaccess. Den delen påminner därför om Spectre som också bara indirekt läcker data.

Men finns också försvårande omständigheter ställt mot MDS, Take A Way är (precis som AMD påpekar) inte orsakad av spekulativ exekvering, det är värre än så då denna sårbarhet därför har långt mindre tighta timing-krav. Saker som temporärt finns fast de inte borde p.g.a. spekulativ exekvering har man 100-200 cykler på sig att "sno" informationen. I praktiken gör det att MDS bara är en realistisk väg om man mycket deterministiskt kan orsaka s.k. undantag, något som går m.h.a. TSX, men utan de instruktionerna (som går att stänga av endera via mikrokod och i nyare system via BIOS) är det ungefär lika sannolikt att bli träffad av en meteorit som att man lyckas utnyttja den svaghet (alla PoC använder sig av TSX).

Man får hoppas att detta kommer från PR, om det kommer från ingenjörer har vi i draftat årets stjärngossetåg

"AMD responded for our request for more information and says there are no new mitigations required, as this issue is covered by the existing side channel attack mitigations."

Just kapaciteten på denna side-channel, när den används som en s.k. covert-channel (två processer som båda är med på noterna pratar med varandra på ett sätt som är sanktionerat av systemet och inte borde vara möjligt) visar hur pass enkel själva sårbarheten är att utnyttja. MDS, när TSX är aktiverat, ger som mest ~28 kbit/s medan Take A Way ger som mest nästan tjugo gånger högre bandbredd (~500 kB/s).

PoC som jag svängde ihop nöjer sig med att läcka 6 bitar per sekund (är tillräckligt för att läcka "0-9a-zA-Z ", d.v.s. en sträng som ger som input till "victim"), är trivialt att öka till 512 bitar / 64 bytes per sekund (storlek på L1D$ (32 kB) dividerat med antal ways (8) dividerat med storlek på cache-line (64)). Borde inte heller vara något problem att läcka den mängden 10-100 gånger snabbare.

Har i.o.f.s. ~20 års erfarenhet av OS-programmering, men tog endast två timmar att skriva en fungerande PoC efter att läst och tagit in vad som står i rapporten. Har bara gjort PoC för varianten som kallas "Load+Reload", den kräver att SMT är aktiverat och förutsätter att man kan tvinga "victim" och "attacker" att köra på olika trådar på samma fysiska kärna.

"Problemet" (egentligen räddningen) är att precis som MDS sårbarheterna (RIDL, Zombie Load, Fallout och Cache Out) är det i praktiken rätt hopplöst att använda denna svaghet till något vettigt med mindre än att man redan har kontroll över dator... Vad ska du men en sådan sårbarhet till om du redan har kontroll över systemet?

Kör du mobilt bank ID: nej, de kan inte sno ditt bank ID
Kör du bank ID på din Ryzen datorn med SMT aktiverat: i teorn, ja. I praktiken, nej så länge du inte frenetisk skriver autentiserar dig om och om igen

Det är inte korrekt. Den andra varianten som går under namnet "Collide+Probe" fungerar vare sig SMT är aktiverat eller ej. Däremot kräver den en s.k. gadget i det kontext man attackerar, vad forskarna gjorde var att skriva en kernel-modul var enda syfte var att erbjuda en sådan gadget (se kapitel "5.3 Leaking Kernel Memory" i rapporten).

I ett verkligt fall måste man hitta en kodsekvens som erbjuder en sådan gadget. Det begränsar vilken typ av data som kan läcka, men just krypto har en tendens att innehålla den typen av gadget då nyckeln används som index in i tabeller i flera algoritmer.

Fast åter igen behöver man i praktiken ha möjlighet att köra valfri kod på systemet som ska attackeras, i.o.f.s. som "vanlig" användare. Ovanpå det måste man kunna anropa lämplig kod i kärnan (eller få en annan process att göra det om man vill läsa data från den processen).

De här CPU-sårbarheterna har typiskt en CVSS på <=7. Det samtidigt som det upptäcktes ungefär två sårbarheter i Windows per månad med CVSS >=9 förra året. Förutom att det är tekniskt enklare att utnyttja sårbarheter i OS fungerar en sådan attack på alla system körandes den OS:et, medan CPU-sårbarheterna i många fall bara fungerar på enskilda modeller och i vissa fall behöver man även kompensera för bakgrundslast och andra faktorer som påverkar CPU-frekvens och därmed timing. Även om just Take A Way är rätt okänslig för timing har ju den sårbarheten problemet att man bara indirekt läcker data, och likt MDS kan man kan inte välja vad som läcks.

OK?

Frågan som då poppar upp: varför ska man ha i åtanke att Intel gett dessa forskare en gåva? Definitionen av gåva är att man får något utan att det förväntas något specifikt motkrav. Så hur man på flera forum på något sätt kan få det till att ett företag som gör enorma vinster väljer att skänka delar av sin vinst (det lär garanterat ge fördelar vid beskattning, så är inte helt p.g.a. att man sätter mänskligheten före sina aktieägare) till något dålig är intressant.

Det här är långt ifrån det enda universitet som får gåvor från företag, i vissa fall utförs specifik grundforskning på uppdrag av företag. D.v.s. företagen väljer specifikt vilka projekt de vill ge pengar till, men universitet värda sitt sigill fortsätter styra den operativa delen i projekten helt efter eget huvud.

Just den här gruppen står bakom majoriteten av säkerhetshålen som hittas i Intels CPUer, men de har även hittat hål i AMD, ARM och PowerPC CPUer.

Det vore direkt korkat av Intel att specifikt finansiera forskning som avser hitta sårbarheter i konkurrenters CPUer. Varje upptäckt sårbarhet är i kronor och ören räknat rejält dyr att hitta, klart dyrare att hitta än att fixa i de flesta fall.

Frågan är om vi kommer få se denna sårbarhet på nyhetsflödet? När man hittar något till Intel ska det visas direkt.
Fö. Lite roligt att användare som älskar AMD kommer in för att förmildra eller förneka i tråden.
Hur var det nu? Amdclockers?

Tycker du att detta är värre en de säkerhetshål som Intel haft, hade det nog inte blivit någon AMD för dig ändå.

Spännande det här, å ena sidan så svarar en personerna bakom upptäckten det här

på frågan om det här är lika illa som Meltdown eller Zombieload.

Å andra sidan så hävdas det i tråden att det nog kan läckas 512 bits åt gången och upp emot 51200 bits/s.

Vem vet, kanske bara allmäna språkproblem.

Kan ju också säga att användningen av data och metadata i personens svar lämnar en bit att önska.

Det här är vad rapporten säger om just detta

"Performance Evaluation. We evaluated the transmission and er-ror rate of our covert channel in a local setting and a cloud setting by sending and receiving a randomly generated data blob. We achieved a maximum transmission rate of 588.9 kB/s (σ ̄x=0.544,n=1000) using 80 channels in parallel on the AMD Ryzen Thread-ripper 1920X. On the AMD EPYC 7571 in the Amazon EC2 cloud, we achieved a maximum transmission rate of 544.0 kB/s(σ ̄x=0.548, n=1000) also using 80 channels. In contrast, L1 Prime+Probe achieved a transmission rate of400 kB/s[59] and Flush+Flush a transmission rate of496 kB/s[30]. As illustrated in Figure 4, themean transmission rate increases with the number of bits sent in parallel. However, the error rate increases drastically when transmitting more than 64 bits in parallel, as illustrated in Figure 6."

Maximala antalet bitar som kan skickas parallellt är 512 på Zen och 256 på Bulldozer. Det är en direkt konsekvent hur cachen är organiserad (kan beräknas från data som är allmänt tillgängligt). Den PoC jag har skickar bara 6 bitar parallellt, tydligen kommer man få rejält med brus om man går över 64 bitar.

Angående meta-data och vad det faktiskt betyder. Man kan inte direkt läcka data m.h.a. denna sårbarhet, det är inte unikt så man har redan färdiga "gadget" för att översätta den implicita information som faktiskt läcks till data som orsakade den implicita informationen. Det kombinerat med denna information från rapporten

är vad som gör transformen från meta-data till data möjlig.

Meltdown är värre då man både kan välja vilken adress som ska läckas, plus att man direkt får data. Zombie Load är värre då den direkt läcker data, men likt Take A Way kan inte inte fritt välja vad som läcks. Det som gör Take A Way värre än Zombie Load är att den är långt mindre timing-känslig, så mycket lättare att skriva en PoC som fungerar på mer än ett enda system.

Ja det säkraste alternativet är att simulera allt i huvudet!

Medans personen kanske menar det, så är det ett stort meme också.

Detta är vanligt om Intel kommer på tapeten på Swec, då hugger AMDClockers direkt