Leuvense onderzoekers vinden kwetsbaarheid in chips van AMD

Onderzoekers van de universiteiten van Leuven, Birmingham en Lübeck hebben een kwetsbaarheid gevonden in chips van AMD. Het probleem werd in februari al bij AMD gemeld en het lek is inmiddels gedicht.

Het team van computerwetenschappers en cryptografen richtten zich tijdens het onderzoek op de communicatie tussen de processor en het systeemgeheugen, dat via een chip genaamd SPD verloopt, schrijft De Tijd. Als een apparaat opstart, geeft die chip door aan de processor wat het beschikbare geheugen is.

De onderzoekers ontdekten dat mogelijk is om de processor te misleiden, waardoor het lijkt alsof er meer geheugen is. Dat creëert een mogelijkheid om de beveiligingstechnologie secure encrypted virtualisation van AMD te omzeilen. Deze beveiligingstechnologie wordt gebruikt om privacygevoelige data in bijvoorbeeld datacentra veilig en versleuteld te bewaren. Door de aanval wordt het mogelijk om toch toegang te krijgen tot deze data en deze zelfs te overschrijven.

Voor de aanval - die BadRAM genoemd wordt - is inmiddels een speciale website gemaakt met meer informatie. Daar vertellen de wetenschappers dat de aanval uit te voeren is met tien dollar aan hardware die gewoon in de winkel te koop is. Voor de aanval is wel fysieke toegang tot de SPD-chip nodig.

De wetenschappers stelden AMD in februari op de hoogte van het probleem, maar maken het nu pas wereldkundig. Op die manier kreeg het bedrijf de tijd om het lek te dichten. De chipfabrikant heeft inmiddels firmware-updates uitgebracht om het probleem te verhelpen.

Reacties (46)

[thunder7]

Het is de spd-chip, niet de sdp chip.

Maar ik vind het gegeven wel ingenieus: je laat de spd-eeprom aan het systeem vertellen dat een ram-chip 2x zo groot is als daadwerkelijk en dan:

adres:
0 1101 -> gewoon geheugen adres, waar een proces niet bij mag
1 1101 -> dit valt binnen de 'extra' ruimte van de chip, dus volgens het systeem hoeft dit niet verboden te zijn, maar de geheugenchip vertaalt het intern naar 0 1101 en kan dan gegevens lezen die niet leesbaar zouden moeten zijn.

Hoe praktisch het is om even de spd-eeprom te herprogrammeren daargelaten, natuurlijk.

[EvelineM]

Excuus, sdp is een tikfoutje. Ik pas dat nog even aan.

[Merik]

Misschien wel handig om te vermelden dat de kwetsbaarheid opgaat voor de AMD Epyc-processoren en niet de Ryzen-reeks, aangezien deze feature bedoeld voor servers is.

[ChielScape]

Ben ik de enige die kwetsbaarheden die fysieke toegang vereisen niet nieuwswaardig vind?

[Verwijderd]

Ben ik de enige die kwetsbaarheden die fysieke toegang vereisen niet nieuwswaardig vind?

Voor de huistuinenkeuken pc wellicht niet.

Maar het betreft hier wel heel specifiek een gat in een beveiliging voor servers die precies daartegen zou moeten beschermen.

[blorf]

Ben je klaar met je draad met transistors aan een chip solderen, blijkt dat je gewoon een ander OS van USB kan opstarten.

[laurxp]

Jij bent niet de doelgroep. Deze aanval laat kwetsbaarheden zien in de technieken die gebruikt worden om bijvoorbeeld de AWS Nitro Enclaves te maken: het hele unique selling point is dat je vertrouwelijke software kan draaien op een cloudmachine zonder dat je blindelings hoeft te vertrouwen dat de cloudprovider geen fysieke aanval uitvoert.

Niet heel relevant voor Jan Janssen die een DIY blog en mailserver draait, wel erg relevant voor een partij als ING of de overheid.

[d3x]

je link naar de tech klopt... maar het totaal verhaal niet... want diegene die dan de memory attack doet, moet dan ook nog physiek op het device kunenn booten of console hebben, moet dan ook nog rechten hebben in het bovenliggende OS etc.... EN EN EN verhaal... al eens bij een cloud provider binnengestapt waar je dit alles kan/mag doen tenzij je toevallig toegelaten word als certified engineer van een onderliggende firma heb je bepaalde rechten, maar zelfs niet alles van dat.

R&D microcode fix bug waardig, media hype NOPE

[Reactie gewijzigd door d3x op 12 december 2024 11:22]

[wooha]

Deze kwetsbaarheid ondermijnt het hele doel van SEV dat op de BadRAM site wordt genoemd. Dat lijkt me behoorlijk nieuwswaardig voor klanten van clouddiensten die op SEV vertrouwen.

Niet voor de gemiddelde lezer van De Tijd, maar Tweakers komt aardig in de buurt.

AMD Secure Encrypted Virtualization (SEV) is a hardware-based trusted execution environment designed to enable secure cloud computing without needing to trust the cloud provider or local law enforcement.

[Amorac]

Als het Israel lukt om tientallen piepers tot bom te maken, is het dan niet aannemelijk dat kwaadwillende iets met deze info kunnen...

[ChielScape]

Als kwaadwillenden in de supply chain zitten zoals met de bompiepers heb ik grotere zorgen dan deze specifieke kwetsbaarheid.

[Amorac]

Maar bedrijven zouden dus moeten weten dat ze mogelijk hierop moeten controleren, dus waarom niet bekend maken via newsites...

Of moet AMD elk bedrijf dat een AMD product heeft gekocht een mailtje sturen? (Alsof AMD weet wie via een leverancier hun product gekocht heeft)

Andere optie is dat een bedrijf elke chip / onderdeel nagaat voor elke server die ze hebben/kopen, maar dat zal voor de meeste bedrijven te kostbaar zijn, dus die kunnen gericht een controle doen als ze zich zorgen maken over deze kwetsbaarheid.

Maar goed, jij vindt het niet belangrijk om te weten, dat kan, maar er zijn dus redenen om het wel te melden.

[Reactie gewijzigd door Amorac op 12 december 2024 09:45]

[bzuidgeest]

Is afhankelijk van hoeveel fysieke toegang vind ik. Dit is niet iets dat je even vlug doet. Heel anders is een exploit die bijvoorbeeld via een beschikbare usb port aan de buitenkant loopt waarvoor je alleen even in hoeft te pluggen. Beide Fysiek, maar van heel andere orde.

Deze is meer een ding als de politie (of fbi etc) je server zou innemen en op die manier toegang kan krijgen. Maar onder normaal gebruik zou het toch op moeten vallen als iemand je server uitzet en nieuwe dingen in soldeert etc...

[pauldebra]

Nou... In een ver grijs verleden hadden wij op de univ een Gould computer met een soort Berkeley Unix (maar niet helemaal). Deze bevatte een nogal knullige kwetsbaarheid waardoor alle gebruikers het hele geheugenbereik dat door de kernel werd gebruikt kon uitlezen. Op de computer werkten studenten en medewerkers (met zo tussen de 10 en 20 gebruikers) tegelijk. Een mooie illustratie van waar dit toe kan leiden is dat elke gebruiker de tty (terminal) buffers van alle terminals continu kon uitlezen. Je kon dus van elke gebruiker onderscheppen wat die allemaal typte (zoals gebruikersnaam en wachtwoord bij het inloggen). Wij hebben deze kwetsbaarheid bij de fabrikant gemeld en die kwam al snel met een aanpassing van de CPU. (Een technicus kwam fysiek op de printplaten van de cpu iets veranderen.) Hierdoor werd het probleem opgelost maar kwam ook aan het licht dat er system calls waren die hun functie uitvoerden door gewoon in user mode de juiste geheugenplek in de kernel uit te lezen. Die system calls werkten plots niet meer. Dus hiervoor was ook nog een software update nodig...
Geloof me, je wil niet dat een systeem dat door alle studenten wordt gebruikt elke student toelaat om alles wat andere studenten (of medewerkers) intypen zomaar mee kunnen lezen!
Ik vond zo'n kwetsbaarheid die fysieke toegang (kunnen inloggen) vereiste toch wel nieuwswaardig en zeker de moeite waard om bij de fabrikant te melden.
Sindsdien zijn de meeste kwetsbaarheden minder knullig en vereisen wat meer speurwerk om ze te vinden...

[beerse]

Het blijkt hier om server-gebaseerde hardware te gaan. Zolang die in een eigen rekencentrum (of bezemkast) staan heb je de volledige controle. Maar als de hardware buiten bereik, in een 'vreemd' rekencentrum, in de cloud of zo staan. Of als ze worden ontvreemd, dan is fysieke toegang niet zo vreemd.

En met die fysieke toegang wil je wel zo veel mogelijk origineel booten. Dan kom je namelijk makkelijker door de versleuteling heen want de keys staan in de bijgevoegde tpm chips en zo. En na een powerdown is meer geheugen niet eens zo heel snel een security issue dat met booten wordt herkent. Vreemde/extra hardware zoals usb-keys en zelfs vreemde toetsenboarden en muizen kunnen security controles al triggeren.

[BCC]

In een tijd dat onze computers niet meer opgesloten op kantoor staan, maar in je broekzak zitten, wordt het imho steeds nieuwswaardiger?

[bzuidgeest]

Als de exploit zonder soldeerbout en open maken kan wel, maar dit... Je bent wel opvallend als je iets open maakt, lekker aan de gang gaat.

[ChielScape]

Klinkt een beetje onlogisch. Een kantoor waar je overdag gewoon vrij naar binnen kan lopen en niet continu iedereen op zijn plek zit om zijn PC te bewaken... vergeleken met een mobiel die je continu in het oog hebt? Niets veiligers dan iets wat je op zak hebt.

[MPIU8686]

vergeleken met een mobiel die je continu in het oog hebt? Niets veiligers dan iets wat je op zak hebt.

Sommigen zetten heel hun leven op een smartphone met alle toegang erbij en overal kom je ze dan tegen. Ze liggen ergens in een goot, op tafels/bankjes, een wandelpad .. vooral als het goed weer is lijk je ze overal te vinden ( dit jaar alleen al 12 smartphones.. ) .. lijkt wel een sport geworden om ze achter te laten. Zeer veilig dus ..


.

[Reactie gewijzigd door MPIU8686 op 12 december 2024 09:14]

[Frankyfreeze]

Tja ik snap dat je het als halve grap brengt maja dan nog, zelfs al zou deze kwetsbaarheid ook werken op een smartphone, hoe ga je toegang tot de chip krijgen en een proces opstarten om bij de data te komen?

Een telefoon openmaken is een stuk minder makkelijk en bij de chip komen zonder per ongeluk iets te slopen is veel lastiger, de ram is vaak gesoldeerd op het MB of op de chip zelf gebakken.

Bovendien tenzij de telefoon unlocked was (unlikely) zal je eerst de beveiliging van Android/Apple moeten breken om een proeces op te starten om bij de data te kunnen komen en eerlijk dan kun je er ook wel bij zonder deze exploit.

[IStealYourGun]

Voor de mainstream media misschien niet, maar voor tech media zoals tweakers is dit wel relevant nieuws imo.

[MPIU8686]

De SPD-chip (Serial Presence Detect - chip)

De SPD (Serial Presence Detect) chip op een geheugenmodule is een extra chip die 128 Hex bytes aan informatie over de module bevat . Dit identificeert de module aan het BIOS tijdens POST, zodat het moederbord de kenmerken en timings kent die gebruikt kunnen worden. Dit werd tegelijkertijd met SDRAM geïntroduceerd.

[rapsac]

.. Dus zit de fout in de bios/uefi van de moederborden, de spd chip is niet (noodzakelijk) van AMD. Vroegah duurde opstarten een eeuwigheid omdat het bios voor het opstarten een geheugen test deed, wat deze kwetsbaarheid zou oplossen.

[d3x]

Wederom veel media buzz en clcik bait voor de websites.... dat vooral een site als "de tijd" dit moet brengen... met hun erbarmelijke buggy site en content die veelal om van te huilen is als het echt over technische dingen gaat. Laat staan over server platformen waar ze totaal niks mee te maken hebben.

leuke bug voor r&d.

Er bestaat ook zoietes (al heel wat jaren beschikbaar in de markt) als certified trusted hw in OEM servers in dit geval dus specifieke dimms. Er wordt niet eens gesproken of deze "kwetsbaarheid" dan wel van toepassing is.

[Reactie gewijzigd door d3x op 12 december 2024 09:30]

[IStealYourGun]

K'vind het wel nog meevallen. Het is niet dat ze beweren dat dit een CVSS score heeft van 9 ofzo. Ze geven gewoon aan dat ze een vulnerability hebben ontdekt en die hebben gedocumenteerd.

[laurxp]

Er bestaat ook zoietes (al heel wat jaren beschikbaar in de markt) als certified trusted hw in OEM servers in dit geval dus specifieke dimms. Er wordt niet eens gesproken of deze "kwetsbaarheid" dan wel van toepassing is.

Het maakt in dit geval weinig uit welke DIMMs je gebruikt. Het probleem is dat AMD's EPYC CPUs de spd-data in de EEPROM chip van het geheugenreepje blindelings vertrouwt. Bij alle DIMMs is de inhoud daarvan aan te passen als je fysieke toegang hebt, en bij sommige DIMMs is de inhoud aan te passen als je roottoegang hebt.

Het aanvalsscenario is voornamelijk cloud servers, die meerdere VMs draaien die van elkaar gescheiden moeten zijn. Met hardware features als Trusted Execution Environments is dit veilig mogelijk, zelfs als een aanvaller fysieke toegang heeft tot de hardware, of de hypervisor heeft binnengedrongen. Je kan daardoor vertrouwelijke processen in de cloud draaien zonder de cloud-provider op haar blauwe ogen te moeten geloven dat het veilig is.

Maar deze aanval laat zien dat AMD's SEV-SNP niet zo veilig is als gedacht. Er waren al aanvallen bekend die honderdduizenden euro's kosten en ingrijpende constante fysieke toegang nodig hadden, maar in dit nieuwe paper demonstreren ze het met kortstondige toegang en een euro of 10, of zelfs zónder fysieke toegang.

[d3x]

nee die zonder fysieke toegang is enkel op consumenten dingetjes en die kortstondige toegang op fysieke hw zou ik maar met een grote korrel zout nemen in echte DC. EN en dan nog EN als je de Trusted keys hebt is er meer nodig dan dat, je moet als het ware admin rechten hebben op hypervisor nieveau om ook maar iets in de buurt te doen van data en voor de persoonlijke consumenten dingetjes heb je idem ditto admin rechten nodig... ver gezocht, zoals gemeld leuke r&d perfect om te mittigeren door leveranciers, totaal niet media buzz waardig, CVE score VERY EXTREME LOW.

[Reactie gewijzigd door d3x op 12 december 2024 11:14]

[laurxp]

Lees het paper. In combinatie met wat andere issues zorgt dit voor een volledige SEV-SNP bypass. Het hele doel van SEV-SNP is om te beschermen tegen een rogue admin, dus iemand die adminrechten heeft op de hypervisor en kortstondige fysieke toegang kan krijgen is precies het aanvalsscenario waar het tegen moet beschermen.

[AntiPasta]

computerwetenschappers

Wat is er gebeurd met 'informatici'? Dit is een anglicisme

[zypthora]

de afstudeerrichting binnen ingenieurswetenschappen heet dan ook gewoon computerwetenschappen.
https://eng.kuleuven.be/s...lor-computerwetenschappen

[B_FORCE]

Voor de aanval is wel fysieke toegang tot de spd-chip nodig.

Dus het is weer een hoop sensatie met een extreem kleine kans, die praktisch gezien aan nul grenzend is.

Ik heb een serieuze vraag.
Waarom worden zulk soort berichten niet gedeeld als "onderzoekers hebben een uiterst kleine kwetsbaarheid gevonden"?

Behalve misschien een klein MKB, is er geen enkel bedrijf of instantie waar je zomaar fluitend binnen loopt.
Laat staan eventjes zomaar een server of andere computer (om het maar even meer algemeen te houden) open haalt, om vervolgens een methode te gebruiken waarvoor tal van andere methoden voor handen zijn die een stuk beter uit te voeren zijn.
Aangenomen dat een bedrijf of organisatie dusdanig interessant is om zoveel risico te nemen om dat uit te voeren.
Dit soort bedrijven en organisaties hebben al een verhoogd veiligheidsbeleid.

De geloofwaardigheid van dit soort berichten gaat met de dag achteruit.
Op deze manier is het voor de iets minder inhoudelijk bekwame medemens lastig te volgen, dus verdiept men zich vaak niet verder dan enkel de titel.

Vervolgens vindt men het raar dat Jan en alleman in de raarste dingen is gaan geloven.
Oorzaak -> gevolg

[Marctraider]

Volgens mij begint de nitpicking op security een beetje uit de hand te lopen. Hysterie.

[gimbal]

Welke hysterie? Dit is echt zo neutraal gegaan als mogelijk is.

[Tozz]

De website geeft aan dat fysieke toegang niet altijd nodig is wanneer de spd chip niet gelocked is

[d3x]

Insider Threats in Cloud Environments
In a cloud environment, employees of the cloud provider or local law enforcement could gain physical access to the hardware. These insiders could trivially modify the SPD chip to enable BadRAM attacks.

Software-Based Attacks
Some DRAM manufacturers fail to properly lock the SPD chip, leaving it vulnerable to modification by operating-system software after boot. This has previously already caused several cases of accidental SPD corruption. Additionally, some manufacturers intentionally leave SPD unlocked in the BIOS to support features like RGB lighting for gaming setups.

je hebt al full sw acces van het device nodig... kans is dus klein en dan ben je al ver, waarom zou een attacker dan nog eens terug gaan..., en de sw access verwijzen ze ineens naar consumenten devices, niet meer naar workstations en servers waar er sowieso standaard BIOS security is.

[Reactie gewijzigd door d3x op 12 december 2024 08:46]

[badnews.nl]

Je hebt ook de “shipper in the middle”. Dus je server gaat door vele handen voor ie in het DC hangt.
En niet iedereen maakt zijn server open om te kijken of alles klopt…

[d3x]

shipper in de middle heeft nadien geen access physiek of sw matig naar het device.... er bestaan ook exact technieken daarvoor als certified platform...

[foobar79]

SVM zal voornamelijk als klant bij Cloud providers worden gebruikt (bv AWS/GCP hebben "confidential" varianten die hier gebruik van maken)
Hiermee kan je in theorie voorkomen dat je cloud-provider meekijkt in het geheugen van je VM omdat je VM kan verifieren dat ie met SVM is geboot.
Hiermee kan je dat dus omzeilen. (ik neem aan dat je VM ook kan zien of dat de hardware is gepatched naar een veilige versie)

Of je de cloud provider genoeg vertrouwd voor de rest daargelaten.

[DrPoncho]

Ze spenderen talloze uren van hun tijd, kennis en kunde hierin om fabrikanten scherp te houden en de consument daarmee veiliger. Om zichzelf bij zinnen te houden gaan ze ook een uurtje brainstormen over een naam. Even wat afleiding. Maar nee hoor, dat is tegen het zere been van wica! Geen vermaak. Doorwerken.

[1234567y]

en een logo! echt ongelofelijk waar mensen tijd en geld voor weten vrij te maken.

[d3x]

die tijd en geld is goed besteed als R&D, heeft echter niks media waarde....