AMD-processors zijn kwetsbaar voor Meltdown-achtig lowleveldatalek

Veel client- en serverprocessors van AMD hebben een lowlevelkwetsbaarheid die datalekken mogelijk maakt. Aanvallers die dit willen misbruiken, moeten wel complexe stappen uitvoeren. Toch is de impact volgens securitybedrijven groot.

AMD waarschuwt voor een nu ontdekte nieuwe vorm van zogeheten sidechannelaanvallen: transient scheduler attacks (tsa). Deze zijn vergelijkbaar met de beruchte processorkwetsbaarheden Meltdown en Spectre, die sinds begin 2018 grote impact hebben gehad. Bij sidechannelaanvallen kunnen kwaadwillenden data buitmaken die een processor verwerkt, bijvoorbeeld door via een andere thread ‘opzij te gaan’ naar threads met beschermde informatie.

De nu onthulde tsa bestaat uit vier kwetsbaarheden die veel AMD-processors treffen. Het gaat onder meer om de eerste tot en met vierde generatie van Epyc-serverprocessors: modellen met de codenamen Naples, Rome, Milan, Milan-X, Genoa, Genoa-X, Bergamo, Siena en Raphael. Daarnaast is de datacenter-gpu AMD Instinct MI300A vatbaar hiervoor. Verder zijn voor pc’s AMD-processors geraakt in de 3000-, 4000-, 5000-, 6000-, 7000- en 8000-series, waaronder Ryzen- en Athlon-, high-end Threadripper-processors en enkele embedded processors.

In sommige gevallen zijn enkele van de tsa-kwetsbaarheden niet van toepassing op bepaalde processormodellen. In andere gevallen heeft AMD geen fix gepland staan. Zo is er volgens de fabrikant bij bepaalde oudere processors geen sprake van gevoelige informatie die via tsa kan uitlekken. Voor de overige processors biedt de chipmaker nu firmware-updates. Daarbij zijn dan ook updates van het besturingssysteem nodig, meldt AMD in zijn securitybulletin.

Twee van de tsa-kwetsbaarheden zijn volgens AMD niet heel ernstig en krijgen het label ‘laag’ in het CVE-systeem. Dit zijn CVE-2024-36348 en CVE-2024-36349. De andere twee zijn ernstiger en ingeschaald op medium. Dit zijn CVE-2024-36350 en CVE-2024-36357.

De kwetsbaarheden zijn als laag of medium gekenmerkt omdat misbruik lastig is. Aanvallers moeten eigen code kunnen uitvoeren op het systeem. Op servers in datacenters kan dat soms al via gestolen inloggegevens. Daardoor kunnen aanvallers mogelijk bij data van andere gebruikers, wat dus ook volledig andere datacenterklanten kunnen zijn.

Securitybedrijven Trend Micro en CrowdStrike noemen het gevaar van de tsa groot. Zij schatten het dreigingsniveau in op kritiek, meldt The Register. AMD heeft de kwetsbaarheden ontdekt na onderzoek naar aanleiding van een nieuw Microsoft-rapport over processorlekken. Microsoft-onderzoekers ontwikkelden hiervoor een tool die isolatie tussen virtuele machines, kernels en processen test. AMD geeft technische informatie en beperkende maatregelen tegen tsa in een eigen paper.

Reacties (33)

[Houtenklaas]

Op servers in datacenters kan dat soms al via gestolen inloggegevens. Daardoor kunnen aanvallers mogelijk bij data van andere gebruikers, wat dus ook volledig andere datacenterklanten kunnen zijn.

Hoeft niet eens gestolen te zijn. VPS huren en je kan met je eigen inlog aan de gang. Mits de boel natuurlijk wel op AMD draait. Maar dat is eigenlijk het enige scenario wat ik kan verzinnen waar het mis kan gaan. Op een niet gedeelde server waar de inlog van gestolen is heb je sowieso al een probleem.

[nopcode]

[...]

Maar dat is eigenlijk het enige scenario wat ik kan verzinnen waar het mis kan gaan.

Dergelijke vulnerabilities trekken elke software "sandbox" in vraag.

In de praktijk heb ik het nog niet gezien, maar er zijn proof of concepts waarmee ze zoon attack uitvoeren via javascript in de browser (en vanuit de browser je RAM uitlezen).

Het geeft ook problemen voor gesloten OSen die apps toestaan (zoals een infotainment system bijvoorbeeld).

[R4gnax]

Als je de whitepaper van AMD leest geven ze aan dat de waarschijnlijkheid dat dit via een website te exploiteren is, zeer laag is. Omdat daarbinnen de processormechanismen die misbruikt moeten worden niet makkelijk benaderbaar zijn.

Je zou dan sowieso al een vulnerability moeten hebben in de JavaScript VM van de browser, waardoor de aanvaller weliswaar nog in een sandbox vast kan zitten maar al wel toegang heeft tot native code. En ook dan is de vraag of dat voldoende is.

Het whitepaper rept er over dat misbruik pas praktisch wordt bij een langdurig open kanaal, bijv. tussen de OS kernel en een malafide of overgenomen/geinfecteerde applicatie.

[uiltje]

Het geeft ook problemen voor gesloten OSen die apps toestaan (zoals een infotainment system bijvoorbeeld).

Of helaas grid computing op je desktop.

[Reactie gewijzigd door uiltje op 11 juli 2025 01:24]

[Metal spoon]

Een beetje hostingpartij virtualiseert de boel natuurlijk, vraag me af of je dan uberhaupt dicht genoeg op de hardware zit met je user om dit te kunnen exploiten.

[foobar79]

Er zit niet echt een software laag tussen de virtualisatie en de CPU mbt van het uitvoeren van de instructies.
Tenminste niet met hardware virtualisatie wat iedereen gebruikt want software virtualisatie is veel te langzaam,.
Als provider kan je er voor kiezen om wat CPU flags te maskeren zodat de VM niet alle instructies "ziet" maar voor de rest zit er dus niet echt software "tussen" (je kan b.v. AVX2 uitschakelen of andere cpu features)

[Matthijs8]

Dit soort lekken kunnen juist gebruikt worden om bij data van andere VM's te komen:
https://xenbits.xen.org/xsa/advisory-471.html

[Orthodroom]

Als je binnenkomt op een vps via gestolen wachtwoorden en vervolgens bij de data van de buren komt kan nog een aanvalsvector zijn.

[the_stickie]

Een kwetsbare shared server is een open goal.

Maar er zijn andere manieren (kwetsbaarheden, socal engineering,...) om tot (zelfs privileged) code execution te komen en vervolgens met deze kwetsbaarheden het geheugen van andere processen te lekken. Dat vergt wellicht een complexe en tot in de puntjes voorbereide doelgerichte aanval - maar als het doel interessant genoeg is, is ook dat de moeite.

[MPAnnihilator]

Onlangs besliste Intel om de Spectre en/of Meltdown fixes weer uit microcode te halen, dus dit wil volgens mij toch zeggen dat het de laatste jaren in praktijk nooit misbruikt is geweest... potentieel klinken dit wel gevaarlijke CVE's, maar ze zijn super lastig uit te voeren met een resem aan als als als... hopelijk kan AMD het fixen zonder veer performantieverlies. Bij Intel viel de performance in memory heavy toepassingen toch dik tegen.

[Matthijs8]

Waarschijnlijk doel je op dit, dat gaat alleen over GPU niveau: nieuws: Ubuntu zet beveiligingsmaatregelen Intel-drivers uit om prestaties te verbeteren
(Of het gaat om nieuwere CPU modellen waar (een deel van) deze aanvallen al in de hardware gefixed zijn, waardoor er minder mitigations in de microcode nodig zijn.)


En bij veel van dit soort aanvallen (inclusief de originele Spectre) werd juist aangeven dat omdat het op hardwareniveau gaat, het bijna niet te detecteren is. Dan is het misbruik in de praktijk ook niet (goed) te meten.

[Reactie gewijzigd door Matthijs8 op 11 juli 2025 10:14]

[Fiander]

Gaat tweakers nog testen of deze patches ook nadelige gevolgen hebben mbt performance/verbruik?

Ik ga er vanuit dat de gevolgen minder erg gaan zijn dan bij Intel spectre, daar was het 30% in bepaalde worst/kaas gevallen. Maar zou het goed vinden wanneer dit toch getest gaat worden.

[johnny2000]

Dan kan je beter een site zoals Phoronix.net in de gaten houden.

Sommige mitigaties/patches voelen wel inderdaad als schieten met een Kanon op een mug.

[PolarBear]

Uit de paper van AMD:

If mitigation is required, AMD recommends OS and hypervisor software execute this VERW instruction whenever the system transitions from trusted to untrusted code, such as when the kernel exits to user-space, or when transitioning from the hypervisor to a VM. Additionally, AMD recommends executing the VERW instruction before the processor enters an idle state through HLT, MWAIT, or an IO C-State. If MWAIT is used, AMD recommends executing VERW before the MONITOR instruction to ensure the processor can transition into lower power states. AMD believes the use of this mitigation may affect system performance. AMD recommends that system administrators evaluate the risk profile of their workloads to determine if mitigation is appropriate for their environment.

[Mars Warrior]

Als ik het document van AMD lees, dan zie ik de 9000 serie er niet in voorkomen en wordt bij de 7000 series expliciet X3D genoemd. Maar dat laatste is me niet helemaal duidelijk

Dat zou betekenen dat de impact op de meest recente CPUs gewoon nul is.

[Adm.Spock]

Een stukje verder wordt ook de "normale" 7000 serie genoemd.

[Robin4]

Zo is er volgens de fabrikant bij bepaalde oudere processors geen sprake van gevoelige informatie die via tsa kan uitlekken.


Leuk dat dit zo in het nieuwsbericht staat. Alleen word er negens aangegeven om welke modellen dit op toepasbaar is.. Zou best wel willen weten welke cpus nou een fix krijgen en welke niet.

[kujinshi]

Men noemt al als geheel Ryzen 3000-8000, grote kans dat het wel redelijk alles in in die series voor consumenten. Dat zijn een hoop processors.

[uiltje]

Ik denk dat dat valt onder "to be continued ... "

[Powerblast]

Komen dit soort updates automatisch via Windows dan binnen of moet je hier zelf actief voor aan de slag? Zie wel meer drivers enzo via windows update automatisch meegaan, maar geen idee of dat voor cpu firmware ook zo is.

[Marctraider]

Als er microcode patches voor gaan komen is het eerst via firmware/bios updates of via Microsoft (bij het booten ingeladen, en kan je eventueel blocken)

Daarna komt de mitigation daadwerkelijk in de hardware chip zelf, en mag je hopen dat de performance penalty minder is dan de eerder benoemde oplossingen.

[Matthijs8]

AMD biedt helaas alleen losse microcode aan voor server CPU's, dus alleen dan heb je het voordeel van laden door het OS tijdens boot. In dit geval zijn altijd PI updates nodig, dus moet je wachten op een BIOS update die dat integreert. De updates zijn door AMD al wel in december en januari uitgebracht, dus je hebt kans dat er al een BIOS update door de fabrikant is uitgebracht. Mijn Thinkpad heeft die eind april al ontvangen.

Voor Intel microcode bood Microsoft overigens in de jaren na Spectre wel vaker een losse KB package aan die je zelf kon instelleren om deze tijden het booten in te laden. Maar daar lijken ze mee gestopt, de laatste die ik kan vinden is van 2022.

[Matthijs8]

Sommige fabrikanten bieden hun BIOS updates aan via Windows update, als die dan staat ingesteld om ook non-windows updates te installeren kan dat dus automatisch. Als je fabrikant dat dus via Windows aanbied en als je uberhaupt een BIOS update krijgt met de fix van AMD.

Bij Intel heb je het voordeel dat ze ook voor non-server hardware losse microcode updates releasen die door het OS geladen kunnen worden in het vroege bootproces, maar Microsoft bood voor Windows alleen losse KB packages aan die je zelf moest installeren en het lijkt er op dat ze daar al sinds 2022 mee gestopt zijn.

[Marctraider]

Dit zat er natuurlijk aan te komen. Performance winst voor Ryzen is leuk, maar voor al die performance benefits zijn vast nog hele leuke exploit vectors te vinden.


Het is vast een kwestie van tijd voordat ook AMD vervelende micropatches gaat krijgen met alle performance degradatie van dien.

[uiltje]

Dit zat er natuurlijk aan te komen. Performance winst voor Ryzen is leuk, maar voor al die performance benefits zijn vast nog hele leuke exploit vectors te vinden.

Tja "we" hebben de hele tijd gefocust op performance en daarna features, en niet op veiligheid. Op een bepaald punt gaat zich dat tegen je keren en geloof me, dat kan een ecosysteem compleet verwoesten. Zie bijvoorbeeld Adobe flash als voorbeeld van hoe het mis kan gaan.

[Microsoftman]

Oeei, heb net mijn nieuwe computer gebouwd met AMD Ryzen 7600X .

Toch nog overstappen naar intel of dit even aanzien?

[graey]

Intel heeft vergelijkbare lekken, microcode patches komen vaak snel en afhankelijk van hoe kwetsbaar je bent (in het geval van deze situatie als niet-server: nul), hoef je die niet toe te passen.

edit:
Jeetje vanwaar deze -1? Dit is toch gewoon het geval?

Het niveau -1 is het afvalputje voor reacties waarvan je liever had gezien dat ze niet geplaatst waren. In deze categorie vallen de flamebaits, trolls, doelloze first posts, zware off-topic berichten zonder enige toegevoegde waarde, misplaatste grappen, onnodig kwetsende reacties en allerlei andere reacties die een onvriendelijk karakter hebben of op andere wijze zijn bedoeld om irritatie of overlast te veroorzaken.

[Reactie gewijzigd door graey op 11 juli 2025 18:23]

[Robin4]

Maakt niet zoveel uit. Over 6 maanden bijvoorbeeld is Intel ook weer eens aan de beurt.

Meestal gaat het van het ene bedrijf naar het andere.. Snap alleen niet waarom.

Vind het wel belangrijker dat er fixen komen.. En zo niet, dan zou ik graag willen weten welke modellen dit niet krijgen.

[Reactie gewijzigd door Robin4 op 11 juli 2025 00:35]

[ybysaia]

@Houtenklaas was me voor.

[Reactie gewijzigd door ybysaia op 10 juli 2025 15:49]

[vectormatic]

Crowdstrike die iemand anders van een kritieje fout beticht, moet niet gekker worden


Kidding aside, lekker weer, maar hopen dat al mn zen 2/3 systemen een patch krijgen, en de performance impact niet te groot is.. wou toch voorlopig nog niet naar zen 5

[eddieveenstra]

Ik hoop dat een eventuele oplossing via een update welke de performance van de cpu benadeelt wel optioneel blijft. Als huis, tuin en keuken gebruiker zie ik zeker gezien de moeite die er gedaan moet worden niet echt noodzaak om dit te doen.