News Zen 5: AMDs CPUs haben kritischen RDSEED-Fehler

[Incredible Alk]

ist das jetzt für den normalen casual user zuhause besonders brisant?

Wenn er keine Software verwendet die die Funktion nutzt (was vermutlich auf gefühlte >95% der User zutrifft) - nein.

Es ist auch nicht unnormal das eine CPU fehler aufweist. JEDE CPU hat Fehler, ob es aber zu einem Problem wird oder nicht, entscheidet darüber ob sie verkauft wird.

Vorsicht - auch alle verkauften CPUs haben Fehler, und zwar oft rund hundert bekannte (und wahrscheinlich weitere Hunderte unbekannte...). Diese Listen werden tendentiell je mehr Jahre die CPU-Architekjtur auf dem Buckel hat immer länger.

Beispiel Intel (70 aktuell bekannte Fehler bei Raptor Lake): https://edc.intel.com/content/www/u...rocessor-specification-update/errata-details/
Bei ArrowLake sinds aktuell "erst" 54 bekannte Fehler: https://cdrdv2.intel.com/v1/dl/getContent/834774

AMD ist da etwas weniger öffentlich, auf die Schnelle findet man nur ältere einzelne Dokumente:
Beispiel https://www.amd.com/content/dam/amd...-tech-docs/revision-guides/56323-PUB_1_01.pdf

Das ist aber bei allen sehr ähnlich und wie gesagt auch bekannt - übrigens werden die allermeisten dieser Bugs auch nie behoben ("no fix planned").
Publik wird sowas nur dann, wenn einer der Fehler große Folgen hat (TLB-Bug bei AMD, Pentium-Bug bei Intel beispielsweise), grob sicherheitsrelevant ist (Spectre, Meltdown etc.) oder... naja, manche Seiten mal wieder ne neue Runde Klicks brauchen.

 

[Mephisto_xD]

Ist eigentlich mehr ironisch gemeint. Klar werden CPUs wie auch Grafikkarten beschnitten, wenn sie die Endkontrolle nicht bestehen. Das ist ja auch völlig klar. Wegwerfen ist Gewinnverlust usw., daher haben wir so viele CPUs & Co der derselben Serie auf dem Markt.

Die vielen Produkte sind künstlich, und haben selten was mit den wirklichen Produktionskosten zu tun. Man muss halt aber allen was anbieten, und kann nicht nur 500€ CPUs verkaufen. Selbst wenn die Yields das hergeben würden. In vielen Fällen werden die "Fehlstellen" sogar künstlich reingelasert, damit man beschnittene Kerne nicht per Firmware Flash reaktivieren kann.

ist das jetzt für den normalen casual user zuhause besonders brisant?

Nein. Ein direkter Angriff auf der Desktopseite ist extrem unwahrscheinlich, es sei denn du erwartest ohnehin Besuch von der CIA.

 

[Titanultra]

Sensible Daten würde ich von AMD CPUs fernhalten

 

[Postguru]

Sensible Daten würde ich von AMD CPUs fernhalten

Was willst du mit deiner Aussage jetzt aussagen ... "Ich bin ein Troll" sowas in der Art ?

 

[BxBender]

Was ein bisschen in der News für den Laien fehlt.
Es sollte erwähnt werden das ein AGESA Update nur via Bios Update erfolgt.

Und sagt das AsRock, die können ja noch gleich passende Anti-Burning-Features reinhauen...hüstel...lol

Sensible Daten würde ich von AMD CPUs fernhalten

weil Intel so sicher ist?? ...ellenlange Mängelliste... diverse Medienberichte der letzten Jahre... hüstel... lol

 

[Mephisto_xD]

Wenn er keine Software verwendet die die Funktion nutzt (was vermutlich auf gefühlte >95% der User zutrifft) - nein.

Mmh, die Funktion wird schon verwendet denke ich. Sicherheitskritisches Bit Rauschen für Kryptografie lebt ja nicht nur auf dem Server, bei jedem HTTPS Zugriff brauchst du im Prinzip Zufallszahlen.

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.

 

[Titanultra]

Was willst du mit deiner Aussage jetzt aussagen ... "Ich bin ein Troll" sowas in der Art ?

Ich würde dir empfehlen, den Artikel zu lesen und ihn dann noch zu verstehen, die Gefahr wird unterschätzt.

 

[DarkWing13]

Ich würde dir empfehlen, den Artikel zu lesen und ihn dann noch zu verstehen, die Gefahr wird unterschätzt.

Nö ,wird sie nicht. Es wird bereits an einer Lösung gearbeitet die wahrscheinlich bereits in einigen Tagen verfügbar sein wird.
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.

 

[Rollora]

Angesichts von 8,315 Mrd. Transistoren pro CCD ist es eher verwunderlich, dass nicht mehr Fehler vorkommen und dazu noch welche, die nicht durch einen Patch der Firmware behoben werden können... mir fällt spontan der Pentium-FDIV-Bug ein, das war ein ganz anderes Kaliber und das bei einer wesentlich weniger komplexen CPU.

Naja CPUs habe eh immer hunderte Bugs,

 

[Olstyle]

Mmh, die Funktion wird schon verwendet denke ich. Sicherheitskritisches Bit Rauschen für Kryptografie lebt ja nicht nur auf dem Server, bei jedem HTTPS Zugriff brauchst du im Prinzip Zufallszahlen.

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.

Eine der Empfehlungen ist "alles 0" nicht als Zufallszahl zu akzeptieren. Das reduziert die Entropie nur geringfügig und dürfte in diversen Implementierungen sowieso schon drin sein.
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.

 

[Desmond_D_James]

Mmh, die Funktion wird schon verwendet denke ich. Sicherheitskritisches Bit Rauschen für Kryptografie lebt ja nicht nur auf dem Server, bei jedem HTTPS Zugriff brauchst du im Prinzip Zufallszahlen.

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.

Die Qualität ist schon reduziert aber meine Mom interessierts nicht. Grund ist, das jede Zahl die der Generator liefert, einzeln betrachtet trotzdem super ist und nur eine bestimmte super Zahl seltener ist, das macht nix. Die einzelne Verbindung ist trotzdem sicher. Zb gab es mal Experimente bezüglich random walk bei Aktienkursen. Und aus den zufälligen Verläufen haben dann manche ermittelt, dass da durchaus Trends sind etc. Also die üblichen Chartanalysen und sonst was. Aber, es ist natürlich klar dass bei zufälliger Kursentwicklung auch mal Trends auftauchen, wenn das nicht so wäre, können es keine Zufallszahlen sein. Und das versteht meine Mom. Und ich bin natürlich noch intelligenter. Ich habe vor vielen Jahren einen Test gemacht und habe einen IQ von 146. Zumindest damals. Kann sich natürlich auch ändern. Aber, ich wäre lieber weniger intelligent und hatte dafür bessere soziale Fähigkeiten. So kann ich nur darauf hinweisen, Alter Schwede ich hab Kopfschmerzen von Grippe Impfung. Hoffentlich konnte ich mich verständlich ausdrücken.

 

[Olstyle]

Grund ist, das jede Zahl die der Generator liefert, einzeln betrachtet trotzdem super ist und nur eine bestimmte super Zahl seltener ist, das macht nix.

Nochmal: es gibt keinen kleinen Bias sondern es wird bei Versagen einfach 0 zurückgegeben ohne den Fehler anzuzeigen.
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.