Google Sicherheitsforscher Tavis Ormandy hat am 24. Juli 2023 eine Schwachstelle in AMD Zen 2-Prozessoren gefunden, die er Zenbleed nennt. Betroffen ist die Zen 2-CPU-Generation (Ryzen 3000/4000/5000 CPUs und die AMD EPYC Data Center Prozessoren). Zenbleed ermöglicht Angreifern geschützte Informationen aus der CPU zu extrahieren und zu stehen, wobei das sogar per Javascript beim Besuch einer Webseite möglich sein soll.
Anzeige
Tavis Ormandy hat seine Entdeckung hier veröffentlicht, AMD ist seit dem 15. Mai 2023 über das Problem informiert, eine Liste diverser Artikel findet sich auf dieser Mitre.org Seite. AMD hat zur Zenbleed (CVE-2023-20593) Schwachstelle inzwischen das Security Bulletin SB-7008 veröffentlicht.
Ein Problem in "Zen 2"-CPUs kann unter bestimmten mikroarchitektonischen Bedingungen einem Angreifer den Zugriff auf sensible Informationen ermöglichen.
Ursache ist, dass unter bestimmten mikroarchitektonischen Umständen ein Register in "Zen 2"-CPUs nicht korrekt auf 0 gesetzt werden kann. Dies kann dazu führen, dass Daten von einem anderen Prozess und/oder Thread im YMM-Register gespeichert werden, was einem Angreifer möglicherweise den Zugriff auf sensible Informationen ermöglicht.
AMD stuft die Sicherheitslücke als mittelschwer ("medium") ein. Tom's Hardware vermutet hier, dass die Daten sich per Javascript beim Besuch einer Webseite extrahieren lassen. Potentiell sind damit alle vertraulichen Daten auf betroffenen Systemen gefährdet. Betroffen durch CVE-2023-20593 sind nach Ormandy folgende AMD Zen 2 -CPUs:
AMD Ryzen 3000 Series Processors
AMD Ryzen PRO 3000 Series Processors
AMD Ryzen Threadripper 3000 Series Processors
AMD Ryzen 4000 Series Processors with Radeon Graphics
AMD Ryzen PRO 4000 Series Processors
AMD Ryzen 5000 Series Processors with Radeon Graphics
AMD Ryzen 7020 Series Processors with Radeon Graphics
AMD EPYC "Rome" Processors
Der Hersteller AMD will Microcode-Updates für die betroffenen Prozessoren freigegeben, wobei diese laut Security Bulletin 7008 im Oktober, November und Dezember 2023 erscheinen sollen. Tom's Hardware hat im Artikel hier eine genauere Liste der betroffenen Prozessoren und eine Übersicht über die Release-Termine der Microcode-Patches veröffentlicht. Die Microcode-Updates sollten über die Board-Hersteller als Firmware-Updates ausgerollt werden. Gegenüber Tom's Hardware hat AMD folgende Stellungnahmen abgegeben:
Anzeige
Die Auswirkungen auf die Leistung hängen von der Arbeitslast und der Systemkonfiguration ab. AMD ist nicht bekannt, dass die beschriebene Sicherheitslücke außerhalb der Forschungsumgebung ausgenutzt wird.
Daraus lässt sich ableiten, das die Microcode-Updates Auswirkungen auf die Leistung der CPUs haben. Von Debian gibt es Security Tracker diesen Eintrag, wo es heißt, dass bereits einige "Source-Pakete" mit dem Fix vorliegen. Neben dem Artikel von Ormandy und dem Beitrag bei Tom's Hardware haben die Kollegen von Bleeping Computer in diesem Artikel einige Informationen zusammen getragen. Aktuell kann ich aber nicht abschätzen, ob die Schwachstelle in der Praxis wirklich ausgenützt werden kann und welche Bedrohung sich konkret ergibt.
Anzeige
Bei "Bleeping Computer" steht geschrieben ziemlich am Ende des Artikels (Übersetzung_EDGE):
Zitat:
"Die praktischen Auswirkungen von Zenbleed auf reguläre Benutzer sind relativ gering, da es lokalen Zugriff auf das Zielsystem und ein hohes Maß an Spezialisierung und Wissen erfordert, um es zu nutzen."
Also dürfte sich bei Privatpersonen das Risiko in Grenzen halten.
Ich habe gestern ein automatisches Firmware-Update auf einem HP-Probook bekommen. Ob da schon ein Patch für dieses Problem enthalten ist kann ich nicht sagen.
Soweit du keine Epic CPU in deinen Notebook hast, wird das nichts damit zu tun haben.
Wenn in besagtem HP-Probook keine EPYC 2-basierte Server-CPU verbaut ist, dann wurde da sicher noch nichts gefixt…
Der Fix ist in deinem Firmware-Update noch nicht enthalten, denn AMD veröffentlicht die Updates (AGESA) erst im Zeitraum "Oktober, November und Dezember 2023".
Dieses neue AGESA müssen dann die UEFI-Hersteller bzw die Mainboard-Hersteller integrieren und dann selber veröffentlichen, damit es die Endbenutzer auch flashen können.
HP selber kann das nicht eigenmächtig machen, denn dafür haben die gar nicht das nötige Wissen und auch nicht die Kompetenz, einfach mal so Microcode-Updates für die CPUs anderer Hersteller zu veröffentlichen.
Für Linux gibt es Microcode-Update-Packs jeweils eines für Intel und eines für AMD.
archlinux[.]org/packages/?name=amd-ucode
Da ist der neue notwendige Patch aber auch noch nicht drin, denn AMD wird die ja erst im Quartal 4 veröffentlichen.
Warum dauert das eigentlich so lange, einen Microcode-Update zu schreiben, wenn man angeblich lediglich die Register auf Null setzen muss, wenn die Sprungvorhersage falsch war und warum wurden falsch geladene Register nicht sowieso standardmäßig gelöscht?
Von einem "automatischen Firmware-Update" aus Windows heraus halte ich auch nichts, denn wenn Windows gerade in diesem Augenblick des flashens irgendwelche Zicken macht, dann ist das Gerät tot, sofern man kein doppeltes BIOS als Fallback eingebaut hat.
Firmware sollte man per USB-Stick über die BIOS-Funktion (Instant-Flash) oder über das mitgelieferte DOS-Programm des Herstellers flashen.
Also da musst du aber nen ziemlich altes MB haben damit sowas noch zu Problemen führt. Aktuelle MB haben entweder ein DUAL Bios/UEFI oder können im Fehlerfall (sogar ohne CPU) von einem dediziertem USB Port per Stick flashen.
Da ist nen "BIOS Unglück" schon seit Jahren ne harmlose Sache!
Der Pro achtete darauf das das BIOS gesockelt war und hatte nen Prommer zuhause ;-P für alle Fälle.
Die Zeiten wo dein Board dann "bricked" war sind Gott sei Dank vorbei.
Ach waren das noch Zeiten wo ein fehler beim overclocken noch in Rauchzeiten endete und nen BIOS flash für Herzrasen sorgte! (Im übrigen nützte es dir da auch nix wenn du von DOS /USB geflshed hast und in dem Moment der Strom ausfiel ;-P )
Bei gedrückter Turbo-Taste, die Älteren werden sich erinnern, war die Chance ein BIOS-Update erfolgreich zu beenden, eher schlechter als 50:50. Da passte ein komplettes BIOS aber auch noch auf eine Diskette.
Ein Hinweis damals lautete: wenn das Flashen nicht korrekt gelingt, bloss nicht den Rechner ausschalten, gleich nochmal Flashen! Geht nur irgendwie nicht, wenn das Flashprogramm während des Flashvorgangs irgendwann plötzlich einfriert und auf keinerlei Tastatureingabe reagiert. Power-Knopf. Aus. Tot.
Es gab damals aber auch Mainboard-Hersteller, die einen guten Support hatten, denen konnte man den BIOS-Chip oder das Board zum neu Flashen schicken und dann wars wieder gut.
bei den "Top" MB Hertsellern war das BIOS gesockelt, konnte man als mit nem Eprommer einfach nen neuen BIOS Chip flashen und problemlos austauschen!
Dann musste man nicht mal einschicken, du musstest nur auf die passende Größe des Biosbaustein achten weil es da auch schon Unterschiede gab!
Da sieht man, dass du von Firmware-Updates unter Windows keine Ahnung hast. Das Flashen erfolgt nämlich nicht, während Windows läuft. Das Firmware-Update wird von Windows in die UEFI-Partition gelegt, und dann wird Windows neu gestartet. Und dann entdeckt das neu startende UEFI-BIOS das neue UEFI-BIOS als Datei in der UEFI-Partition und flasht selbst.
Wie funktioniert das, wenn man keine UEFI-Partitionen (EFI-Systemressourcentabelle ESRT) hat, also MBR statt GPT Partitionsstil benutzt?
Die Funktion UpdateCapsule benötigt ein UEFI mit mindestens der Spezifikation 2.8, was ist wenn man ein älteres UEFI hat?
UpdateCapsule braucht mindestens Windows 8.
Was ist, wenn man noch das bessere Windows 7 benutzt?
Was passiert, wenn man ein Mainboard zum Beispiel von Medion hat, das aber von MSI hergestellt wird?
Wie erkennt denn Windows dann "Medion" statt "MSI"?
Man muss dort nämlich ein spezielles Medion BIOS flashen und sollte nicht das MSI-BIOS benutzen.
Seit 24.7.2023 gibt es den ersten Microcode FIX von AMD für Linux:
"Fix an issue on AMD Zen2 processors called Zenbleed.
The bug manifests itself as a data corruption issue when executing VZEROUPPER under certain microarchitectural conditions"
mit diff:
git[.]kernel[.]org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0a9266b79cacdd02b888aed1308c308ad6d4ee4e
für AMD Family 17h (Zen / Zen+ / Zen 2):
git[.]kernel[.]org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=0bc3126c9cfa0b8c761483215c25382f831a7c6f
Am selben Tag in der selben Minute hat AMD aber auch Microcode-Updates für AMD Family 19h (Zen 3 / Zen 3+ / Zen 4) veröffentlicht. Sind die vielleicht auch irgendwie von Zenbleed betroffen):
git[.]kernel[.]org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=b250b32ab1d044953af2dc5e790819a7703b7ee6
Zusätzlich gibt es seit dem 24.7.2023 einen Linux-Kernel-Patch, der das chicken-Bit setzt, als Workaround gegen Zenbleed:
"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."
mit diff:
git[.]kernel[.]org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.4.y&id=9b8bb5c4e25678af895dc9dd4a1e82b2f948cacc
Da es diese Microsode-Updates bereits seit Montag 24.7.2023 gibt, warum werden dann die neuen AGESAs erst im Zeitraum "Oktober bis Dezember 2023" veröffentlicht?
Im DIFF sieht man, für welche CPU der Microcode-FIX gilt:
+ Family=0x17 Model=0x31 Stepping=0x00: Patch=0x0830107a Length=3200 bytes
– Family=0x17 Model=0x31 Stepping=0x00: Patch=0x08301072 Length=3200 bytes
git[.]kernel[.]org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=0bc3126c9cfa0b8c761483215c25382f831a7c6f
Family=0x17 Model=0x31 ist "Rome oder Castle Peak".
en[.]wikichip[.]org/wiki/amd/cpuid
Rome ist EPYC 7002 (also nicht alle EPYC, sondern nur EPYC ZEN2):
en[.]wikichip[.]org/wiki/amd/cores/rome
en[.]wikichip[.]org/wiki/amd/epyc#7002_Series_.28Zen_2.29
Castle Peak ist Ryzen Threadripper Generation 3, also Threadripper 39xx
en[.]wikichip[.]org/wiki/amd/cores/castle_peak
en[.]wikichip[.]org/wiki/amd/ryzen_threadripper
Die normalen Ryzen haben also noch keinen Microcode FIX erhalten.
Seltsamerweise weiß niemand, was dieses chicken Bit 9 ("DE_CFG[9]=1" ) überhaupt deaktiviert ("chicken" ist ein synonym für "coward", also Angsthase).
Selbst der Entdecker dieser Schwachstelle Tavis Ormandy weiß das nicht.
Zitat:
taviso commented Jul 26, 2023
"Sorry, only AMD can answer that question – you know as much as we do!"
github[.]com/google/security-research/issues/36#issuecomment-1650908996
In den Beiträgen davor wurde erwähnt, dass auch in allen verfügbaren Dokumentationen über die AMD-CPUs dieses spezielle Bit nicht erklärt wird.
Woher weiß dann Tavis Ormandy, dass man mit diesem Bit (DE_CFG[9]) die betreffende Funktion (welche ist das) abschaltet?
lock[.]cmpxchg8b.com/zenbleed.html
Tavis Ormandy kann unmöglich von selber auf diesen Workaround gekommen sein, was er auch selber zugibt.
Da muss AMD ihm diesen Tipp gegeben haben, ohne aber zu erklären, was dieses Bit genau bewirkt.
Mit den msr-tools kann man dieses Bit setzen, schreibt Tavis Ormandy:
wrmsr -a 0xc0011029 $(($(rdmsr -c 0xc0011029) | (1<<9)))
"DE_CFG[9]=1" entspricht dann wohl 0xc00011029 [dort das Bit 9 = 1 setzen]
Im Abschnitt "C001_1029" steht dieses spezielle Bit 9 aber nicht erwähnt:
lore[.]kernel[.]org/lkml/20170425114541.8267-1-dvlasenk@redhat.com/
Auch im Stackoverflow-Forum kennt niemand die Bedeutung dieses chicken-Bits 9:
stackoverflow[.]com/questions/76763069/amd-de-cfg9-documentation
Nun wurde dieses chicken-Bit 9 aber bereits in den Linux-Kernel integriert, obwohl niemand außer AMD genau weiß, welche Funktion dadurch abgeschaltet wird und welche Seiteneffekte das hat.
Solche Voodoo-Patches halte ich für suboptimal.
Meiner Meinung nach sollte man genau wissen, was da passiert, bevor man etwas patcht, aber das hat AMD bisher nichtmal dem Tavis Ormandy offen gelegt.
Das Bit-9 schaltet eine neue geheime Überwachungs- und Protokollierungs-Funktion in den AMD-CPUs frei. Der Bitstream wird direkt per WLAN auf Musks Starlink-Satelliten hochgeschickt und bei AMD in Huston/Texas empfangen und zum Ausspionieren der Benutzer verwendet. >;-D
Weißt du denn, welches Bit die "geheime Überwachungs- und Protokollierungs-Funktion" tatsächlich einschaltet bzw ausschaltet oder kannst du garantiert ausschließen, dass es solche Funktionen gar nicht gibt?
Es gibt da zum Beispiel ein undokumentiertes "HAP field" in dem Intel CPU master controller ("High Assurance Platform", entwickelt von der NSA und eingebaut in den Binärblobs der Firmware).
Die NSA konnte diese Funktion für eigene Rechner abschalten, damit sie nicht vom Feind ferngewartet werden können.
Normale User können das nicht und bleiben daher potentiell fernwartbar und überwachbar.
Das Hacker-Tool "me-cleaner" funktioniert auch nicht überall.
www[.]csoonline[.]com/article/562761/researchers-say-now-you-too-can-disable-intel-me-backdoor-thanks-to-the-nsa.html
Es gab mal einen ziemlich heftigen Streit zwischen Google und Intel, weil Google lieber CoreBoot auf seinen Servern haben wollte, aber feststellen musste, dass Intel unentfernbare Sperren eingebaut hatte, und Intel sich hartnäckig weigerte, diese Binärblobs entfernbar zu machen oder deren Sourcecode zu veröffentlichen.
CoreBoot wäre doch zweifellos besser und Intel könnte weiterhin seine CPUs verkaufen, wenn man CoreBoot einsetzen würde, aber trotzdem weigert sich Intel. Warum ist das so, wenn es nicht irgendwelchen staatlichen Zwang für solche speziellen Features gibt?
AMD hat die Versionsnummern und Daten der AGESA Versionen veröffentlicht, mit denen das Problem gefixt werden wird:
AMD Ryzen 3000 Series Desktop Processors "Matisse":
AGESA ComboAM4v2PI_1.2.0.C
AGESA ComboAM4PI_1.0.0.C
Dezember 2023
AMD Ryzen 4000 Series Desktop Processors with Radeon Graphics "Renoir" AM4:
AGESA ComboAM4v2PI_1.2.0.C
Dezember 2023
AMD Ryzen Threadripper 3000 Series Processors "Castle Peak" HEDT:
AGESA CastlePeakPI-SP3r3 1.0.0.A
Oktober 2023
etc:
CastlePeakWSPI-sWRX8 1.0.0.C
ChagallWSPI-sWRX8 1.0.0.7
CezannePI-FP6_1.0.1.0
RenoirPI-FP6_1.0.0.D
MendocinoPI-FT6_1.0.0.6
www[.]amd[.]com/en/resources/product-security/bulletin/amd-sb-7008.html
Danach müssen die Mainboard-Hersteller diese neuen AGESA in ihre UEFIs einbauen und neu veröffentlichen.
ZEN2 ist eventuell bei manchen Mainboard-Herstellern schon End-of-Life, da älter als 2-3 Jahre und dann gibt es eventuell gar keine Updates mehr.
Microcode-Updates können ja auch vom Betriebssystem (Linux/Windows/… die können das alle) beim ersten Start nach Einschalten in die CPU reinladen. Das ist ein bischen später, als wenn das PC-BIOS das erledigt, deswegen aber sicher kaum unsicherer als wenn das BIOS das macht.
Also, kein Grund zur Panik.
Wenn eine Malware Injektion bereits aktiv im Bios ist, nützt dir das laden aus dem OS raus nur nix mehr…denn da kann die Malware das bereits aktiv verhindern … also ja das ist sehr wohl unsicherer. (funktioniert also nur solange das BIOS/UEFI noch "jungfräulich" ist, ist es bereits infiltriert hast du bereits verloren)
Im heise Newsticker-Artikel gab es eben ein Update mit einer Liste der betroffenen CPU-Modellnummern in Tabellenform:
www[.]heise[.]de/news/Zenbleed-Sicherheitsluecke-in-allen-Zen-2-CPUs-von-AMD-9226172.html