Zen 5: AMDs CPUs haben kritischen RDSEED-Fehler
Es klafft eine kritische Sicherheitslücke im hardwarebasierten Zufallszahlengenerator RDSEED von AMDs Zen-5-Prozessoren. AGESA-Updates sollen nachhelfen.
AMD hat das Vorhandensein eines RDSEED-Fehlers auf CPUs mit Zen-5-Architektur bestätigt, darunter die Ryzen-9000-Reihe, AI Max 300, Threadripper 9000 und Ryzen Z2. Die als schwerwiegendes Problem mit der Bezeichnung "AMD-SB-7055" (CVE-2025-62626) eingestufte Sicherheitslücke in dem hardwarebasierten Zufallszahlengenerator könnte dazu führen, dass Schlüssel ausgegeben werden, die nicht vollständig unvorhersehbar sind, was wiederum ausgenutzt werden kann.
Die RDSEED-Anweisung auf Zen-5-Chips gibt demnach auf nicht zufällige Weise "0" zurück und meldet den Fehler fälschlicherweise als Erfolg. Betroffen sind die 16-Bit- und 32-Bit-Formate der RDSEED-Anweisung, während die 64-Bit-Version aus Gründen, die AMD nicht näher erläutert hat, offenbar nicht von dem Problem betroffen ist, wie Tom's Hardware hierzu berichtet.
RDSEED-Fehler bei Zen 5: AGESA-Updates kommen
Es handelt sich dabei um ein kritisches Problem für Kryptografieanwendungen, die auf die Zufallszahlengenerierung angewiesen sind, um vollständig unvorhersehbare Kryptografieschlüssel bereitzustellen. Wenn RDSEED ausfällt, sind entsprechende Anwendungen anfällig für Angriffe, wenn der Fehler zu einem vorhersehbaren Zeichenmuster führt. RDSEED ist neben RDRAND eines von zwei Systemen zur Erzeugung von Zufallsschlüsseln, die auf modernen CPUs (einschließlich Intels) verfügbar sind.
Das Problem wurde zuerst von einem Meta-Ingenieur entdeckt, der es in der Linux-Kernel-Mailing-Liste bekannt gab, wie Phoronix bereits Mitte Oktober berichtete. Einige Tage später wurde als Workaround ein aktualisierter Linux-Patch veröffentlicht, der RDSEED auf allen Zen-5-Chips deaktiviert, um die Sicherheitslücke zu schließen. AMD will in Kürze AGESA-Mikrocode-Updates über OEMs veröffentlichen, um das Problem auf allen Zen-5-CPUs zu beheben. Als vorübergehende Abhilfe empfiehlt AMD in seinem Security-Bulletin unter anderem die 64-Bit-Variante von RDSEED zu nutzen oder die CPUID zu verschleiern.
Ihre Meinung ist gefragt!
Was sagen Sie zu dem Fehler? Nutzen Sie die Kommentarfunktion und teilen Sie uns Ihre Meinung mit. Beachten Sie beim Kommentieren aber bitte die Forenregeln. Folgen Sie uns außerdem für Neuigkeiten in der Hardware-Welt oder unsere exklusiven Inhalte gern auf Whatsapp und X. Unsere Video-Inhalte (oftmals gewürzt mit einer Prise Humor) finden Sie bei Youtube, Instagram und Tiktok.
Das ist ein bisschen schlechter als "ein bisschen weniger super". Allerdings dürfte man für typische Krypto Schlüsselgrößen eh die 64Bit Version benutzen und 0-Schlüssel sowieso unterdrücken.
Aber wenn tatsächlich jemand einen 128Bit Schlüssel mit der 32Bit Variante baut hat man plötzlich eine Chance auf reale 96Bit Sicherheit, die wird schon als grenzwertig angesehen.
Der Unterschied ist aber, dass sich ein Angriff auf eine einzelne HTTPS Verbindung über einen CPU Fehler der manchmal die zufälligkeit der Zufallszahlen etwas einschränkt schlicht nicht lohnt.
Der Unterschied ist aber, dass sich ein Angriff auf eine einzelne HTTPS Verbindung über einen CPU Fehler der manchmal die zufälligkeit der Zufallszahlen etwas einschränkt schlicht nicht lohnt.
Andersherum werden Angriffe die Schlüssel mit "alle Bits gesetzt" oder 0, als Folge mutmaßlich ganz stillstehender Zufallsgeneratoren, ausprobieren wohl routinemäßig überall mit laufen. Noch ein Grund solche Schlüssel sowieso systematisch zu verbieten.
Das arbeitet der Artikel vielleicht auch zu wenig heraus:
Der Fehler besteht darin dass zu häufig 0 als Zufallszahl kommt. Vermutlich (hier ist man wohl noch am untersuchen) weil das Error Bit nicht immer gesetzt wird wenn gar kein Ergebnis generiert wurde.
Es sind also nicht alle Zufallszahlen kompromittiert durch einen generellen Bias, sondern nur genau die Häufigkeit von Nullen ist fragwürdig hoch.
Zen 5 gibt es bereits eine Weile. Ist deshalb die Welt der Kryptografie zusammengebrochen, weil überall PCs und Server gehackt wurden?
Nein. Und wenn der Fehler nicht zufällig(!) entdeckt worden wäre, würde sich auch nichts wesentlich ändern.
Oft ist die Entdeckung und Veröffentlichung des Fehlers, das größere Problem als der Fehler selbst.
Ich möchte gar nicht wissen, wie viele dieser "Fehler" noch in CPUs schlummern, und die vielleicht nie jemand entdecken wird.