News Zenbleed: Sicherheitslücke gefährdet Zen-2-Architektur von AMD

[_casual_]

Puh, da bin ich ja rechtzeitig auf ZEN 4 umgestiegen

Naja, zumindest bis da was platzt. Blauäugig wäre es zu denken, ein Hersteller ist mehr davor gefeit als ein anderer.

Mit Hardware CVEs werden wir noch mehr tun bekommen (hoffentlich). Je mehr rauskommt, umso besser.

 

[Lemiiker]

Leistung >> Sicherheit. Der Performance -Killer aka Patch kommt nicht auf meinen Gaming-PC.

 

[Conqi]

Wäre sicherlich auch sehr interessant, die gleiche Forschung an SoCs für Smartphones durchzuführen. Wer weiß, was da alles im Argen liegt und für Privatnutzer vielleicht sogar stärkere Auswirkungen hätte...

Meltdown betraf auch die Performance ARM Cortex Kerne damals. In die Richtung wird also durchaus auch geschaut.

 

[0x8100]

• Family=0x17 Model=0x08 Stepping=0x02: Patch=0x0800820d Length=3200 bytes
• Family=0x17 Model=0x01 Stepping=0x02: Patch=0x0800126e Length=3200 bytes

laut wikichip ist das zen+ (0x08) und zen (0x01). die können natürlich updates bekommen haben, sollten aber nach aktuellem stand nichts mit zenbleed zu tun haben.

 

[0x8100]

@Whistl0r
ich würde mal vermuten das der Microcode im Linux repo für alle Zen2 CPUs gilt nicht nur für Epic Server.

nein, je nach cpu-model gibt es einen anderen patchstand. und im zenbleed-fix im kernel wird für die verschiedenen zen2 cpus jeweils dieser patchstand abgefragt und dann entschieden, ob es einen softwarefix gibt oder nicht:

+static bool cpu_has_zenbleed_microcode(void)
+{
+    u32 good_rev = 0;
+
+    switch (boot_cpu_data.x86_model) {
+    case 0x30 ... 0x3f: good_rev = 0x0830107a; break;
+    case 0x60 ... 0x67: good_rev = 0x0860010b; break;
+    case 0x68 ... 0x6f: good_rev = 0x08608105; break;
+    case 0x70 ... 0x7f: good_rev = 0x08701032; break;
+    case 0xa0 ... 0xaf: good_rev = 0x08a00008; break;

wie man sieht ist hier epyc als model 0x31 bereits mit good_rev = 0x0830107a vorhanden. dieses patchlevel ist ja auch in den releasenotes für den aktuellen microcode erwähnt. interessant ist, dass zen2 ryzen (matisse -> model 0x71) schon mit good_rev = 0x08701032 vorhanden ist. das würde ja bedeuten, dass die gefixte microcode-version für die ryzens ja schon feststeht (und sogar schon irgendwo vorhanden ist?)

 

[SSD960]

Ich hoffe der fix wird möglichst schnell ausgeliefert.

Vermutlich Ende 23. Das ist nicht schnell. Leider

 

[sNo0k]

Meine Güte, das war die vorletzte Prozessorgeneration von AMD auf AM4, und nun werden 4 Jahre später Schwachstellen gefunden, solange hat doch der Großteil der Forennutzer das System nicht in Betrieb...

 

[lukas12342]

Es fällt schon deutlich auf, dass findige Lückenexperten AMD immer nur 1-2 Monate Zeit einräumen bis sie Sicherheitslücke öffentlich machen.

Echt unverschämt und gehört, falls das alles zutrifft verklagt.

Nicht der Sicherheitsexperte hat die Lücke voreilig öffentlich gemacht sondern AMD hat dies getan. Keine Unverschämtheit vom Sicherheitsexperten sondern Inkompetenz Seitens AMD das es noch keinen Microcode für Consumer CPU gibt.

2023-07-20 AMD unexpectedly publish patches, earlier than an agreed embargo date.

Spoiler

https://lock.cmpxchg8b.com/files/zenbleed-v5.tar.gz

- `2023-05-09` A component of our CPU validation pipeline generates an anomalous result.

- `2023-05-12` We successfully isolate and reproduce the issue. Investigation continues.

- `2023-05-14` We are now aware of the scope and severity of the issue.

- `2023-05-15` We draft a brief status report and share our findings with AMD PSIRT.

- `2023-05-17` AMD acknowledge our report and confirm they can reproduce the issue.

- `2023-05-17` We complete development of a reliable PoC and share it with AMD.

- `2023-05-19` We begin to notify major kernel and hypervisor vendors.

- `2023-05-23` We receive a beta microcode update for Rome from AMD.

- `2023-05-24` We confirm the update fixes the issue and notify AMD.

- `2023-05-30` AMD inform us they have sent a SN (security notice) to partners.

- `2023-06-12` Meeting with AMD to discuss status and details.

- `2023-07-20` AMD unexpectedly publish patches, earlier than an agreed embargo date.

- `2023-07-21` As the fix is now public, we propose privately notifying major distributions that they should begin preparing updated firmware packages.

- `2023-07-24` Public disclosure.

Und bevor ich hier geflamt werde ich habe auch zen2 Systeme...

 

[Senephar]

Unter Linux wird das ganze mit den aktuellsten Kerneln durch setzten des chicken bits bei Systemen ohne Microcode update vorerst behoben.

Author: Borislav Petkov (AMD) <bp@alien8.de>
Date: Sat Jul 15 13:41:28 2023 +0200

x86/cpu/amd: Add a Zenbleed fix

commit 522b1d69219d8f083173819fde04f994aa051a98 upstream.

Add a fix for the Zen2 VZEROUPPER data corruption bug where under
certain circumstances executing VZEROUPPER can cause register
corruption or leak data.

The optimal fix is through microcode but in the case the proper
microcode revision has not been applied, enable a fallback fix using
a chicken bit.

Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Kernel 6.4.6, 6.1.41, 5.15.122, 5.10.187, 5.4.250, 4.19.289


Microsoft wird garantiert was ähnliches mit nem Windows-Update auch einführen.

 

[Skysnake]

Mäh, das wäre natürlich sehr sehr unglücklich von AMD....

Ich bu zum Glück durch mit dem late Update des microcodes. So ganz klar ist mir aber noch nicht was er genau macht. Immerhin geht wohl der POC nicht mehr mit dem Update.

Was ich mich aber frage ist was passiert wenn ne Anwendung doch noch die Instruktion verwenden will. Segfaulted die oder wird nen alternativer Code ausgeführt, der die Instruktion emuliert????

Weil unter Linux kann man die Insteuktion ja wohl auch ohne miceocode Update einfach ausschalten.

@Redaktion vielleicht könnt ihr da mal etwas Aufklärung betreiben.

 

[chaopanda]

Solche Lücken sind doch nur bei relevanten Geschäftsgeheimnissen und deren Abläufen oder Staatsgeheimnissen interessant für einen Angreifer. Bei irgendwelchen Normalusern ist doch eh nichts zu holen beziehungsweise gibt es einfachere Methoden diese auszuforschen.

Weil die Personen im Home Office ja auch alle mit dem neuesten Shit im HW-Bereich unterwegs sind und immer genau wissen, wo sie drauf klicken... Ja ne ist klar.
Das Einfallstor hier ist größer als bei Spectre. Da muss Druck von AMD kommen, dass da schnell Updates gefahren werden und nicht erst zu Weihnachten was kleckerweise raus geht. Am besten über Windows Updates, das man das so ja möglichst breit verteilt bekommt.

 

[TempeltonPeck]

Wie war das noch mit dem "Wasser kochen" ?

Ich kann mich noch genau daran erinnern wie hier bestimmt 70% der AMD Boys sich gefeiert haben, dass sie AMD gekauft haben, weil Intel ja so typisch inkompetent ist.

Das hier ein Patch Monate auf sich warten lassen wird, ist gerade bei dieser Schwere; absolut inakzeptabel.

Dann solltest du dich auch noch daran erinnern können das es um Intels Umgang damit ging. Erst ignoriert, dann klein geredet, anschließend Patch angekündigt der ohne Leistungseinbußen auskommen sollte um dann doch Einbußen mit sich zu bringen.

Was die Wartezeit auf Patches betrifft so muss bedacht werden das erst einmal eine Lösung für das Problem entwickelt werden muss. Dann implementiert und anschließend getestet weden. Das ist keine Sache von Tagen. Klar sollten solche Patches schnell kommen aber so einfach ist es halt nicht. Insbesondere wenn man bedenkt das solche Probleme kurzfristig auftreten (Projekt und Personalmanagment)

 

[Intruder]

wieviel Wahrheit dran ist = 🤷‍♂️ wer weiß es schon...
was ähnliches gab es glaube schon mal vor 10 Jahren.

NSA May Have Backdoors Built Into Intel And AMD Processors

Man weiß nie, ob die "Sicherheitslücke" zufällig oder absichtlich implementiert wurde und wenn es öffentlich wird, huch es war ein Bug..... und nun müssen wir das beheben und im Hintergrund wird wieder am nächsten "Bug" gearbeitet.

Wie gesagt kann ich nicht beurteilen ob an der Theorie was dran ist oder nicht.
Dennoch sehr interessant sowas zu lesen.

 

[dev/random]

Es fällt schon deutlich auf, dass findige Lückenexperten AMD immer nur 1-2 Monate Zeit einräumen bis sie Sicherheitslücke öffentlich machen.

Intel wurde häufig mindestens 6 Monate zugestanden oder Intel hat sich noch längeres Stillschweigen mit Druckausübung erzwungen, bis die Lücken letztlich veröffentlicht wurden.

Mal abgesehen von der unnötigen Polemik - die meisten Sicherheitsforscher halten sich nur an ihre eigene Vulnerability Disclosure Policy, denn sie haben auch einen Ruf zu verteidigen (oder erwerben).
In diesem Fall ist sicherlich die 90-Tage Policy von Google zum Tragen gekommen, nur dass AMD den ersten Patch vorschnell veröffentlicht hat.

 

[ElecEng]

Ich hab nur 4650g bei Kunden Deployed als opnsense Hardware Appliances

Ist doch völlig egal, wenn die Firewall Bare-Metal läuft? Wenn ein Angreifer so weit ist, dass er Code auf der FW ausführen kann, ist er eh schon drin.
Wäre nur dann ein Problem, wenn man die Firewall als VM neben einer DMZ-VM laufen hat. Wobei selbst dann fraglich ist, welche kritischen Daten sich im RAM einer FW finden - ist ja schließlich nur Lesezugriff die Sicherheitslücke.
Cloud-Anbieter sind da erheblich mehr von betroffen.

 

[Hibbelharry]

Da ist irgendwas bei der Veröffentlichung schiefgegangen, nur was? Verschiedene Orte listen da verschiedene Stories, ich weiss nicht was stimmt.

Aber mal laut in die Allgemeinheit gedacht:
Wenn AMD im Mai informiert wurde und man weiss, dass bis zur Offenlegung normal grob 6 Monate vergehen, dann ist die Consumerkisten bis Ende des Jahres fixen grob im Industriestandard.

Es ist auch gut, dass Epyc bereits versorgt ist, Auf Mehrnutzersystemen ist das ganze ja sachlich am ekeligsten.

Der Linux Kernelpatch sieht fair aus, demnach sind alle Kisten mit aktuellem Linux Kernel bereits safe, Stand heute, nur eben je nachdem wohl mit ziemlich leichten Performanceeinbussen.

Den Spectre/Meltdown Vergleich zu Zenbleed find ich witzig. Das sind beides (naja, genauer: alle 3 ...) Sicherheitslücken, aber der Einschlag ist jeweils ganz anders.

Zenbleed ist nicht schön, aber verstanden und vergleichsweise cheap zu fixen.

Meltdown war ein Intel Ding, in quasi allen Intel CPUs ab 1995, Spectre hat quasi alle Hersteller getroffen. Diese Lücken für bereits veröffentlichte CPUs zu beheben ist teilweise unmöglich, so dass sich mancher Programmcode seitdem stumpf verbietet und die Behebung kostet teilweise erhebliche Performance.

Zenbleed ist ne kleine Macke bei bestimmten, quantitativ eingeschränkten CPU-Befehlen, damit ziemlich klein. Spectre und Meltdown sind CPU Architektur Kenschmelzen. Besonders Intel hats so richtig verkackt. Und das meint nicht nur die Marketing Stunts bei der Veröffentlichung, das meint vor allem auch die technische Basis der CPUs.

Ich würde 20 Zenbleeds nehmen, bevor ich nochmal ein Spectre/Meltdown haben wollte. Ich will das alles nicht, aber das ist NICHT dasselbe.

 

[Caramon2]

Sogar heise schreibt diesen Blödsinn, dass es noch Monate dauern wird: https://www.heise.de/news/Zenbleed-Sicherheitsluecke-in-allen-Zen-2-CPUs-von-AMD-9226172.html

Dabei kam gestern früh schon diese Meldung: https://www.phoronix.com/news/Linux-Mitigate-Zenbleed

 

[Atlan3000]

Wenn tatsächlich nur Zen2 CPUs betroffen sind, bin ich froh schon länger auf Zen3 umgestiegen zu sein. Bei den aktuellen Zen3 Preisen, kann ich das auch nur jeden Zen2 Besitzer raten, nach einem Bios Update die CPU einfach zu tauschen. Dann muß er nicht auf Patches warten und leicht schneller ist er dann auch unterwegs.

 

[mkl1]

Sogar heise schreibt diesen Blödsinn, dass es noch Monate dauern wird: https://www.heise.de/news/Zenbleed-Sicherheitsluecke-in-allen-Zen-2-CPUs-von-AMD-9226172.html

Dabei kam gestern früh schon diese Meldung: https://www.phoronix.com/news/Linux-Mitigate-Zenbleed

Nicht heise schreibt das, sondern AMD selber. Wurde hier schon verlinkt: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7008.html

AMD plans to release to the Original Equipment Manufacturers (OEM) the AGESA™ versions on the target dates listed below. Please refer to your OEM for the BIOS update specific to your product.

Bei Matissa, Lucienne, Renoir, Mendocino wird die entsprechende AGESA erst im Dezember bereitgestellt. Diese kann dann von den Board Herstellern ins Bios integriert werden.

Übrigens hat AMD die Schwachstelle am 24.7 selber veröffentlicht. Es ist schon wieder typisch, wie hier versucht wird, die Schuld von AMD auf andere zu schieben.

 

[Hibbelharry]

Bei Matissa, Lucienne, Renoir, Mendocino wird die entsprechende AGESA erst im Dezember bereitgestellt. Diese kann dann von den Board Herstellern ins Bios integriert werden.

Ein Detail am Rande: Klar enthält AGESA CPU ucodes, aber sowohl Linux als auch in Windows können beim Start anderen ucode laden. Der einzige Punkt mit AGESA ist eigentlicht, dass das dann komplett OS unabhängig funktioniert.

Noch n Punkt, hatte ich weiter vorne schon mal: 6 Monate von einer Meldung eines Problems bis zur Bereitstellung von Patches ist nicht so schrecklich ungewöhnlich in der Industrie. Sieh dir gerne mal an wielang Intel da zum Beispiel bei Sprectre/Meltdown rumgekocht hat.

Ungewöhnlich ist nur dass so früh Details bekanntgeworden sind. Meistens werden Patches verteilt und erst hinterher gesagt was los ist, wenn der schon bei den meisten im System ist. Die Lücken treffen dann nur diejenigen die nie etwas patchen.

Nicht heise schreibt das, sondern AMD selber. Wurde hier schon verlinkt: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7008.html

In dem AMD Dokument sagt AMD es gibt etwas, und das patched man so und so. Sie sagen dort nicht wie die Lücke funktioniert. Es spricht auch nichts dagegen früh Abhilfemassnahmen und Pläne strukturiert zu kommunizieren.

Es spricht nur etwas dagegen die Wege zur Ausnutzung so früh zu dokumentieren.

Übrigens hat AMD die Schwachstelle am 24.7 selber veröffentlicht. Es ist schon wieder typisch, wie hier versucht wird, die Schuld von AMD auf andere zu schieben.

Es ist auch typisch, dass Leute einfach nicht genau lesen.