wurstkuchen
BIOS-Overclocker(in)
Alle Ryzen5000 also Zen3 sind davon alle nicht berührt?
News Zenbleed: Sicherheitslücke bedroht jetzt alle Zen-2-Prozessoren von AMD
- Ersteller PCGH-Redaktion
- Erstellt am
hrIntelNvidia
BIOS-Overclocker(in)
Doch, ganz genauso. Und es betraf ja nicht nur Intel, nur Intel stärker als AMD...
Schnitzelnator
Software-Overclocker(in)
Ja, Zen 3 ist nicht berührt.
Nein, auch 5000er sind betroffen, wenn sie Zen 2 basiert sind. Z.B. Notebook CPUs wie Ryzen Mobile 5700U.
Infi1337
Freizeitschrauber(in)
Abwarten, speziell die VM Backends scheinen wie seit jeher vermutet schon immer eine Sicherheitsseuche.
Der M1/M2 ist auch anfällig für Sidechannelattacks über einen SMC Exploit, der wahrscheinlich schwerwiegender ist als bisher zumindest der Zenbleed oder gar SpectreV1.
Apple bezahlt wahrscheinlich im Vergleich zu Intel, AMD und Google deutlich schneller und mehr Schmiergeld, daher hört man davon nichts.
Der M1/M2 ist auch anfällig für Sidechannelattacks über einen SMC Exploit, der wahrscheinlich schwerwiegender ist als bisher zumindest der Zenbleed oder gar SpectreV1.
Apple bezahlt wahrscheinlich im Vergleich zu Intel, AMD und Google deutlich schneller und mehr Schmiergeld, daher hört man davon nichts.
Schonmal einen Server mit M1 oder M2 CPU gesehen? Für PCs haben die Lücken alle überschaubare Auswirkungen.
saphira33
Software-Overclocker(in)
Ich bin ja nicht nur in diesem Forum unterwegs. Ich red vom allgemeinen "Feedback".
Bert2007
PCGH-Community-Veteran(in)
Ich warte auf deine Spende ?Zum Glück sind meine beiden Ryzen keine Zen 2, ich muss gestehen das ich aufgeatmet habe, denn damals der ScheiC mit Intel hat mir gereicht, ich habe keine Lust etwas ähnlich nerviges nochmal durchzumachen.
Ich fühle mit euch liebe Zen2 Nutzer, aber womöglich ist das der nötige schubs den ihr braucht um auf Zen 3 aufzurüsten, der 5800X3D wartet auf euch
Adresse per PM ?
Zumindest für einige Leute, durchgängig nicht-Intel-Nutzer, war die Existenz eines Exploits Anlass genug, noch Jahre später zu flamen.
Die Leistung wurde eher selten angesprochen. Dafür gab es ja auf Seiten von Hardcore-Fans auch wenig Anlass – AMD war und ist bei Verwendung der gleichen Hardware-Fixes genauso betroffen (ARM ebenfalls), überwiegend wird aber sowieso nur die Software gehärtet und wo doch mal die von Intel initiierten Befehle zum Einsatz kommen, werden zwar beispielsweise Datenbankserver hart getroffen, aber keine Spiele-Systeme. Vor allem aber hatte Intel in letzteren damals noch Vorsprung, sodass man selbst mit Fixes gegen ein ungepatchtes AMD-System gewonnen hat. "Haha, deine CPU ist immer noch schneller als die von meinem Lieblingshersteller" taugt eher schlecht zum flamen. "Haha, CPUs von deinem Hersteller sind total unsicher" schon eher.
Im mobilen Bereich trifft es dank AMDs Rebranding sogar die 7020er.
Allerdings geben weder AMD noch Tavis Ormandy explizit an, dass das Problem bei z.B. Zen 3 nicht auftreten kann. Scheinbar wurde es zufällig auf einem Zen-2-System entdeckt, sofort gemeldet und jetzt nach Bereitstellung eines Fixes gepublished. Von intensiven Prüfungen auf anderen Rechnern ist nicht die Rede, aber da die Sprungsvorhersagen von Zen 1, Zen 4 oder Alder Lake nicht identisch zu Zen 2 arbeiten, können bereits relativ kleine Unterschiede im Exploit große Unterschiede bedeuten: "Sicherheitslücke prinzipiell vorhanden, aber nur mit Code-Anpassungen ausnutzbar" lautete zum Beispiel in vielen Spectre-Fällen das schlussendliche Fazit für diverse Architekturen, inklusive AMD. Aber das zu erforschen dauert, vor allem wenn man die anderen Architekturen nicht gut genug kennt, während man eine 1:1-Kopie des Codes binnen weniger Stunden geprüft hat.
Man muss keine Verschwörungstheorien auspacken, um eine geringe Präsenz von Apple in der Sicherheitsforschung zu erklären:
Die CPUs haben einfach einen zu kleinen Marktanteil.
Als die Spectre-Welle damals los ging, konnte AMD auch 1-2 Jahre mit "keine betroffenen CPUs bekannt" auftreten, weil überhaupt niemand nachgeguckt hat – Zen war noch neu, Bulldozers Marktanteil absolut unbedeutend, zumal bei Servern. Wenn alle mit Haswell oder Skylake arbeiten, wird halt auch nur dort etwas gefunden. 3-4 Zen-Generationen ist AMD wichtig genug, um auch dort aktiv zu suchen, aber für Apple interessiert sich niemand.
saphira33
Software-Overclocker(in)
Ja das seh ich schon ein.
Ich hatte damals ein i7 3770.
Wieso man einen "Lieblingshersteller" hat den man Verteidigen muss versteh ich nicht.
Alle können gute sachen und schlechte sachen machen.
Und dem Unternehmen bin ich als Einzelperson am ende des Tages einfach nur Sch*ss egal.
Ich habe mir das jetzt mal grob durchgelesen. Das ist meinem Verständnis nach wieder so ein Ding, das hauptsächlich die Cloud und Nutzer von virtuellen Servern betrifft, wo dann ein unbekannter Nachbar auf dem System mithören kann. Selbst dedizierte Server haben somit eigentlich kein Problem. Genau wie bei Intel damals.
Es ist wieder einmal einfach tausendmal leichter, einem Nutzer einfach eine Malware unterzujubeln, die einfach im Rahmen der Nutzerrechte läuft und die Daten direkt abgreift. Da muss man dann auf keine Prozessorgeneration zielen, um dann unvollständige Daten relativ gesehen Tröpfchenweise abzuziehen, sondern kann eine ganze Betriebssystemreihe addressieren, egal auf was die läuft und alles, was der Nutzer sehen darf, so schnell runterziehen, wie sein Upstream erlaubt oder man maximal machen möchte, um nicht aufzufallen. Hätte also für PCs nur eine Relevanz, wenn da noch andere Benutzer gleichzeitig Programme drauf laufen haben.
ΔΣΛ
PCGH-Community-Veteran(in)
Den Satz verstehe ich nicht, kritische Äußerungen sollen, wenn ein ähnlicher Umfang eintreffen sollte, deutlich weniger vorhanden sein ... weil? Weil heute hier mehr Leute eine AMD CPU haben als damals? Klingt nicht logisch.
Damals, beim Meltdown & Spectre Problem, haben mehr Leute eine Intel CPU gehabt ...
Die damalige Kritik kam sicher nicht überwiegend von nicht betroffenen AMD Nutzer, vielmehr von den betroffenen Intel Nutzern.
Ist ja nicht so das die damaligen Intel Nutzer (ich war einer von ihnen) die Leistungsverminderungen toll gefunden haben, nur AMD Nutzer ein Problem sahen.
Ich bezweifle stark das heute die AMD Nutzer und/oder die Artikel dazu, wenn eine deutliche Leistungsverminderung eintreten sollte, weniger kritisch sein werden.
Infi1337
Freizeitschrauber(in)
Die gute alte Verschwörungstheorie https://arxiv.org/abs/2306.16391.
Bei Intel und der Verbreitung ihrer CPUs suchte man deine reflektierte Sichtweise aber vergeblich, da hatte AMD auch noch keine Marktanteile und es sind ja immer die Guten und so klein usw.
. Da wird Immer schön mit zweierlei Maß gemessen.Für Apple interessiert sich schon jemand, es riskiert halt keiner ne dicke Lippe und man macht lieber Werbung für die Brille zum Kleinwagenpreis.
Wie stark die M1/2 schon verbreitet sind ist doch völlig unerheblich, je nach tatsächlicher Schwere sind Sicherheits relevante Bedenken bei ihrer eigenen Hardware für sie doch katastrophal, abgesehen davon sind ARM CPUs die am weit verbreitetsten überhaupt
.
Nach einer Million (!) Verschlüsselungsoperationen durch den Angreifer ist es gelungen, die Hälfte (!) eines statischen (!) AES128 (!) Key von einem anderen User-Mode-Programm zu rekonstruieren (Erfolg gegen Kernelmode: Nicht so detailiert angegeben, aber um mindestens eine Größenordnung schlechter)? Mit massiv abnehmendem Qualitätszuwachs der Ergebnisse bereits nach ein paar Zehntausend Durchgängen, sodass eine Demonstration für die vollen 128 Bit vermutlich aus gutem Grund unterlassen wird, von einer Versuch mit AES256 ganz zu schweigen?
Da muss wirklich jemand tief unter den Teppich gekehrt haben.
Solche Lücken sind für alle Systeme eine Gefahr, die fremden Code in Turing-tauglichen Formaten ausführen. Neben Cloud-Servern gehören dazu auch alle Privatrechner auf denen man zum Beispiel legal fragwürdigen Inhalte aus ungesicherten Quellen öffnet, auf denen Spiele-Demos von unbekannten Entwicklern ausprobiert werden oder auf denen schlicht Javascript aktiv ist. Mein (unerfülltes) Lieblingsszenario war lange Zeit immer ein Angriff auf Ethereum-Miner aus einem Smart-Contract heraus.^^
Allerdings sinkt die Gefahr gegen Null, solange derartige Lücken einigermaßen zügig geschlossen werden. Sie zu finden und zu implementieren ist enorm aufwendig im Vergleich zu schnödem Phishing und würde sich gegen Privatpersonen nur lohnen, wenn ein einmal gefundener Exploit danach lange Zeit unbemerkt ausgenutzt werden kann. Technisch sind die Voraussetzungen dafür eigentlich gegeben, denn die Angriffe hinterlassen keine Spuren außerhalb des Angreiferthreads selbst. Aber sobald kompetentere Leute daran forschen und die Firmen aktiv dagegen vorgehen, haben nur noch große, bezahlte Teams eine realistische Chance, einzelne, wenige Targets in einem beschränktem Zeitraum damit anzugreifen, bevor jemand anderes die gleiche Lücke zufällig findet und schließt. Wer nicht im Clinch mit großen Konzernen oder Staaten liegt, passt nicht in dieses Muster.
Da muss wirklich jemand tief unter den Teppich gekehrt haben.
Solche Lücken sind für alle Systeme eine Gefahr, die fremden Code in Turing-tauglichen Formaten ausführen. Neben Cloud-Servern gehören dazu auch alle Privatrechner auf denen man zum Beispiel legal fragwürdigen Inhalte aus ungesicherten Quellen öffnet, auf denen Spiele-Demos von unbekannten Entwicklern ausprobiert werden oder auf denen schlicht Javascript aktiv ist. Mein (unerfülltes) Lieblingsszenario war lange Zeit immer ein Angriff auf Ethereum-Miner aus einem Smart-Contract heraus.^^
Allerdings sinkt die Gefahr gegen Null, solange derartige Lücken einigermaßen zügig geschlossen werden. Sie zu finden und zu implementieren ist enorm aufwendig im Vergleich zu schnödem Phishing und würde sich gegen Privatpersonen nur lohnen, wenn ein einmal gefundener Exploit danach lange Zeit unbemerkt ausgenutzt werden kann. Technisch sind die Voraussetzungen dafür eigentlich gegeben, denn die Angriffe hinterlassen keine Spuren außerhalb des Angreiferthreads selbst. Aber sobald kompetentere Leute daran forschen und die Firmen aktiv dagegen vorgehen, haben nur noch große, bezahlte Teams eine realistische Chance, einzelne, wenige Targets in einem beschränktem Zeitraum damit anzugreifen, bevor jemand anderes die gleiche Lücke zufällig findet und schließt. Wer nicht im Clinch mit großen Konzernen oder Staaten liegt, passt nicht in dieses Muster.
Zuletzt bearbeitet:
Ich bin mir nicht ganz sicher, ob man das Szenario per Interpreter wirklich hinbekommt und den könnte man dann vielleicht auch einfach entsprechend ändern. Aber stimmt schon, Javascript ist da so ein Sonderfall, weil man sich davor halbwegs sicher fühlt, weil das quasi in einer VM im Browser läuft. Alles, was der Nutzer als er selbst auf Systemebene ausführt, bedarf eigentlich keiner CPU-Lücke.
rum
BIOS-Overclocker(in)
Ob meine Zockerkiste gehackt wird, ist mir tatsächlich so egal wie das Wissen um die Durchschnittsdichte der Außenhaut von Schilfohr und mein Arbeitsrechner arbeitet mit Zen1+Debian. Naja nicht ganz .. hast schon recht; Zen3 lockt, aber eher mit der Performance.Zum Glück sind meine beiden Ryzen keine Zen 2, ich muss gestehen das ich aufgeatmet habe, denn damals der ScheiC mit Intel hat mir gereicht, ich habe keine Lust etwas ähnlich nerviges nochmal durchzumachen.
Ich fühle mit euch liebe Zen2 Nutzer, aber womöglich ist das der nötige schubs den ihr braucht um auf Zen 3 aufzurüsten, der 5800X3D wartet auf euch
"Chicken Bit Dingen"?
Workaround
It is highly recommended to use the microcode update.
If you can’t apply the update for some reason, there is a software workaround: you can set the chicken bit DE_CFG[9].
This may have some performance cost.
Gibt wohl Tools auf GitHub dafür. Ich glaube einen Weg für Laien gibt es nicht wirklich. Ich höre auch zum ersten Mal von den MSRs. Aber ich glaube damit sind auch eher Systemadmins angesprochen. Da es Register sind, müsste man den Wert auch nach jedem Neustart neu setzen.
Lamaan
Software-Overclocker(in)
Soll das heißen, bei dem aktuellen Exploit Zenbleed nimmt die Erfolgsrate beim Suchen der geheimen Daten exponentiell ab, bis zu nahe Null Erfolgschance bei erreichen von 50% der erforderlichen Daten ?Nach einer Million (!) Verschlüsselungsoperationen durch den Angreifer ist es gelungen, die Hälfte (!) eines statischen (!) AES128 (!) Key von einem anderen User-Mode-Programm zu rekonstruieren (Erfolg gegen Kernelmode: Nicht so detailiert angegeben, aber um mindestens eine Größenordnung schlechter)? Mit massiv abnehmendem Qualitätszuwachs der Ergebnisse bereits nach ein paar Zehntausend Durchgängen, sodass eine Demonstration für die vollen 128 Bit vermutlich aus gutem Grund unterlassen wird, von einer Versuch mit AES256 ganz zu schweigen?
Da muss wirklich jemand tief unter den Teppich gekehrt haben.
Das würde diesem Angriff schon einiges von dem Schrecken nehmen.
Es gibt ja so einige Funktionen an denen man ewig rechnen kann und nie das Zeil erreicht, weil man mit jedem Ergebnis bzw. Zwischenschritt 50% weniger erreicht (z.B. können auch 80% sein) und somit schnell nahe 0% Fortschritt geht.
Bei einer 128Bit Verschlüsselung wäre die Gefahr dann quasie 0, zumal Verschlüsselungen nun auch nicht immer mit statischen Schlüsseln arbeiten, sondern den Schlüssel auch bei jeder Anfrage neu erstellen können.
Zuletzt bearbeitet:
Ähnliche Themen
