News Ryzen und Epyc: Sicherheitslücke betrifft alle aktuellen AMD-Prozessoren

[boonstyle]

Und ich hatte schon gehofft, das AMD nicht die gleichen oder ähnliche Fehler begeht wie Intel.....

Weil alle Menschen Fehler machen nur die Mitarbeiter bei AMD nicht?

Absolut absurd zu denken, dass AMD nicht von Sicherheistlücken betroffen ist. Das liegt in der Natur der Dinge Fehler in Produktionen erst im Nachhinein zu erkenne bzw. dass später mit neuen Techniken und Ansetzen Lücken geschaffen werden.

BMW ruft tausende Fahrzeuge zurück, da die gelieferten Aribags schlicht nicht funktionieren, ist das selbe, es wird etwas konzipiert, getestet, produziert und am Ende gibt es Umstände, welche zum Versagen oder Fehlern führen z.B: Produktionsmaschinendefekte etc.

 

[CableGuy82]

Versteh ich das korrekt?
Die Forscher bekamen für gefundene Lücken in Intels Produkten Geld von Intel und sollen deshalb nun im Auftrag von Intel Fehler in AMD-Prozessoren suchen, wo dann aber kein Geld mehr von Intel raus springt, weil man ja keine Lücken in Intel Produkten gefunden hat?

Ich verstehe es so (Achtung: Gefährliches Halbwissen!), dass die Uni Geld/Material für die Suche nach Lücken in Mikroprozessoren bekommt. Ich glaube nicht, dass es dabei explizit "nur Intel" oder "nur AMD" heißt, sondern "Mikroprozessoren". Meinetwegen x86-Architektur (sonst wäre das Feld riesig), aber eben ohne "Label" bzw. "Farbe".

 

[Kuomo]

Antivirussoftware wird da sicher helfen, und um ganz sicher zu gehen sollte man noch eine Atemschutzmaske vor jeden Lüfter schnallen.

 

[cypeak]

Als AMD Fan kann ich dir genau das sagen was AMD selber sagt. Kein Produkt ist 100% frei von Sicherheitslücken. Wer etwas anderes behauptet ist einfach dumm.

ja, wobei die hersteller hier auch ein stückweit selbst schuld sind: die iterationzyklen zw. prozesorren und auch zwischen architekturen sind wesentlich kürzer geworden und somit ist auch das ausgiebige abtesten gerade auf solche lücken nicht gründlicher geworden.
dazu kommt dass immer mehr funktionalität in die hardware gegossen wird: management engines, tpm's..

 

[cbtestarossa]

Container schützen vor Lücken aber nicht, bei der man Daten abgreifen kann, die eigentlich für Zugriffe gesperrt sein sollten.

Das wissen wir. Aber besser man schaltet so etwas ein, denn es erschwert Angriffe.
Das selbe gilt für Site-Isolation oder JS-Blocker und Dingen wie uBlockOrigin.
Zusätzlich empfiehlt sich sowieso alles nicht benötigte im Broser zu deaktivieren.
Zusätzlich blockt man noch alle Drittanbietercookies usw.

Was die CPUs angeht.
Solange alles nach Schema F weiterläuft, ist denk keine Besserung in Sicht.
Von Neuman ist am Ende, besser alles neu machen.
Könnte auch sein dass gewisse Dinge dadurch einfacher werden.

 

[jemandanders]

Wow.
Was hier großteils abgegangen ist, war ja echt Kindergarten.
Anstatt sich vielleicht noch aus anderen Quellen Informationen zu besorgen wird hier Geknüppelt ohne Gnade.

Natürlich ist jeder Fehler in einem Sicherheitskonzept schlecht. Wenn ich mir das aber mal genauer anschaue, kann ich mit diesem L1D Fehler durchaus noch leben. Mit der nächsten CPU könnte der Fehler auch schon behoben sein. Muss man mal schauen, ob noch Zeit war, das beim ZEN3 Design zu beheben. Das grundsätzliche Konzept, scheint jedenfalls weiterhin zu stehen.

Ganz anders sieht mir das bei der Management Engine aus. Dort droht der absolute GAU. Wenn es gelingt den Root of Thrust aus dem ROM auszulesen, ist kein Intel-System dieser Welt, mit den betroffenen CPUs mehr sicher.
Als Lektüre empfiehlt sich z.B. http://blog.ptsecurity.com/2020/03/intelx86-root-of-trust-loss-of-trust.html
Die Jungs haben sich scheinbar das wohl größte, -nicht Intel eigene- Wissen um die ME erarbeitet.
Wenn die sagen, es ist Gefahr im Verzug, dann ist es so.
Damit Signiere ich jeden Mist, welchen ich, wem auch immer unterjubeln will und keine Soft- und/oder Hardware dieser Welt, wird mich aufhalten.
Ich glaube, das ist nur den allerwenigsten klar. Dagegen war Meltdown Kindergeburtstag.

Edit: Noch ein Auszug aus dem Blog. Mit google übersetzt:

Hier ein paar Worte zur Sicherheitslücke selbst:



1. Die Sicherheitsanfälligkeit ist sowohl in der Hardware als auch in der Firmware des Boot-ROM vorhanden. Die meisten IOMMU-Mechanismen von MISA (Minute IA System Agent), die externen DMA-Agenten Zugriff auf SRAM (statischer Speicher) von Intel CSME gewähren, sind standardmäßig deaktiviert . Wir haben diesen Fehler entdeckt, indem wir einfach die Dokumentation gelesen haben, so unscheinbar das auch klingen mag.

2. Die Intel CSME-Firmware im Boot-ROM initialisiert zuerst das Seitenverzeichnis und startet die Seitenübersetzung. IOMMU wird erst später aktiviert. Daher gibt es einen Zeitraum, in dem SRAM für externe DMA-Schreibvorgänge anfällig ist (von DMA zu CSME, nicht zum Hauptspeicher des Prozessors) und initialisierte Seitentabellen für Intel CSME bereits im SRAM enthalten sind.

3. MISA IOMMU-Parameter werden zurückgesetzt, wenn Intel CSME zurückgesetzt wird. Nach dem Zurücksetzen von Intel CSME wird die Ausführung mit dem Boot-ROM erneut gestartet.

Daher kann jedes Plattformgerät, das DMA für den statischen Speicher von Intel CSME ausführen und Intel CSME zurücksetzen kann (oder einfach darauf wartet, dass Intel CSME den Ruhemodus verlässt), Systemtabellen für Intel CSME-Seiten ändern und dadurch den Ausführungsfluss nutzen. Autor : Mark Ermolov, Positive Technologies

Wenn jmd. sich mal die Dokumentation von Intel antun möchte,worin auch eine Beschreibung der ME enthalten sein soll, welche eigentlich nicht mehr öffentlich zugänglich ist, kann ja mal zur wayback machine gehen und dort den ursprünglichen -jetzt toten- Link eingeben. Vielleicht lässt sich dort ja was finden.
https://www.intel.com/content/dam/w...eleron-n-series-j-series-datasheet-vols-3.pdf
Aber Vorsicht. Das sind, falls ihr was findet, fast 5000 Seiten.

 

[[wege]mini]

dass die Uni Geld/Material für die Suche nach Lücken in Mikroprozessoren bekommt.

Leider funktioniert das Verteilen von Geldern in Universitäten nicht so, wie du es dir vorstellst.

Ich war über 15 Jahre dabei, konnte mich aber persönlich nie dazu selbst erniedrigen, in diesem unwürdigen Schauspiel mit zu machen.

Menschen ausbilden, andere Menschen am anderen Ende der Welt tot zu schießen (hab ich auch schon gemacht)....kein Problem. Meine Leistung wird gewürdigt, weil Menschen zurück kommen und nicht Särge.

Menschen an Universitäten "verbilden"....nicht mit mir.

Wenn du Geld aus der "freien Wirtschaft" bekommst, ist das Ergebnis schon fest stehend und du verkaufst nur deinen guten Namen.

Das darf gerne jmd. anderes machen.

mfg

p.s.

und das ist kein Schwachfug gelaber....vor über 20 Jahren "durfte" ich für den deutschen Staat Menschen mit Dingen bilden, die sind heute einfach nur unglaubwürdig.

Wenn mir jmd. was von Filesharing erzählt, lächel ich immer müde^^
Raubkopieren^^
Gangster Rapper^^
Clan Kriminalität^^

wir durften nicht da hin, wo es gebrannt hat, weil keine Killer Kommandos gewollt waren sondern Brunnen Buddler. ^^

Universitäten sind mMn einfach nur dafür da, den aktuellen Status quo zu bewahren und sicher zu stellen, dass sich nichts ändert.

Echte Entwicklungen, kommen aus Garagen und von Freaks/ Nerds.

 

[cbtestarossa]

Wusste schon Bill Gates und andere Größen welche das Studium abbrachen.
Dort wird meist nur sinnlos Zeit mit Uraltwissen verbrannt. (Gibt aber auch Ausnahmen)

Das selbe aber auch schon vorher.
Selbst Harald Lesch und andere meinten dass das Schulsystem überholt ist.
Es bildet eher nur gehorsame unterwürfige Systemerhalter aus die wiederum später das selbe tun.
Man zerstört quasi wissbegierige Kinder schon mit 6 Jahren.

 

[Ned Flanders]

Ok, bin jetzt auch mal dazu gekommen das Paper durchzulesen. Also so wie ich das ganze verstehe, was durchaus nicht endgültig krorrekt sein muss, (bitte korregieren) erlaubt es die Lücke ausschließlich Adressen die zur virtuellen Indizierung der Caches abgelegt sind zu leaken. Also NUR durch einen predictor vorhergesagte Adressdaten aber absolut keine Daten Programdaten geschweige denn Daten aus dem Kernelspace.

Warum das eine "Sicherheitslücke" ist, erschließt sich mir beim besten Willen tatsächlich nicht und bevor mir da einer Befangenheit vorwirft, dass würde ich bei jedem Hersteller so sehen.

 

[CableGuy82]

Leider funktioniert das Verteilen von Geldern in Universitäten nicht so, wie du es dir vorstellst.

Ich war über 15 Jahre dabei, konnte mich aber persönlich nie dazu selbst erniedrigen, in diesem unwürdigen Schauspiel mit zu machen.

Menschen an Universitäten "verbilden"....nicht mit mir.

Wenn du Geld aus der "freien Wirtschaft" bekommst, ist das Ergebnis schon fest stehend und du verkaufst nur deinen guten Namen.

Das klingt bedenklich...

 

[karl_laschnikow]

Naja diese zwei Sicherheitslücken bei AMD machen es den Angreifer leichter als bei Intels 90. Schließlich kann er sich dort auf die beiden Lücken voll konzentrieren. Während die 90 bei Intel ihn verunsichern welche nun genutzt werden könnte.

Spaß beiseite. Kann gut möglich sein das AMD bald genau so viele Lücken hat. Wenn auch diese Lücke mir ungefährlich erscheint...

 

[Kasjo]

Ich glaub das bleibt sich auch gar nicht aus.

 

[zEtTlAh]

1000 mal geprüft, getestet, nochmal geprüft, für Sicher befunden...

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

passiert halt...

 

[Pocketderp]

Ok, bin jetzt auch mal dazu gekommen das Paper durchzulesen. Also so wie ich das ganze verstehe, was durchaus nicht endgültig krorrekt sein muss, (bitte korregieren) erlaubt es die Lücke ausschließlich Adressen die zur virtuellen Indizierung der Caches abgelegt sind zu leaken. Also NUR durch einen predictor vorhergesagte Adressdaten aber absolut keine Daten Programdaten geschweige denn Daten aus dem Kernelspace.

Jep, du siehst das schon richtig. Gäbe es eine Methode um zusätzlich auf die besagten Inhalte zugreifen zu können sähe es schon deutlich anders aus. Amd spricht ja selbst davon das diese Lücke ja bereits geschlossen ist, ob dies nun das direkte Auslesen anging oder geht bzw ob man sich nun auf diese Lücke bezieht das ist hier die Frage. Aus meiner Sicht wäre ja so einige Prozessoren seit 2011 betroffen, incl so einiger A10 etc.

 

[Piktogramm]

Warum das eine "Sicherheitslücke" ist, erschließt sich mir beim besten Willen tatsächlich nicht und bevor mir da einer Befangenheit vorwirft, dass würde ich bei jedem Hersteller so sehen.

Prozess kann (Meta-)Daten außerhalb seines Speicherbereiches abgreifen/beeinflussen und damit ist es eine Lücke. An der Stelle wird man innerhalb des Fachbereiches kaum diskutieren. Die Bewertung der Lücke ist dann gern mal etwas unscharf.

 

[Ned Flanders]

@Piktogramm

Ok, so gesehen macht das natürlich Sinn.

Ist das eigentlich ein Journal Paper? Für einen Life Scientist ist das Medium in dem hier veröffentlich wird irgendwie unklar. Auf der Frontpage ist kein J ersichtlich, auch nicht ob das durch einen Peer Review gegangen ist. Wird es wohl sein nehme ich an. Es hat aber einen DOI nur führt der link ins leere und oben auf den Seiten steht etwas von eine Konferenz im Juni diesen Jahres. Die anderen Veröffentlichungen sahen aber afaik gleich aus.

 

[Piktogramm]

Schaut sehr nach Paper zu besagter Konferenz aus, wobei (etwas unüblich) das Paper vor der Konferenz veröffentlicht wurde.

Die Forschergruppe bzw. Daniel Gruss, scheint generell wenig in Journals zu veröffentlichen sondern eher frei bzw. auf Konferenzen. https://gruss.cc/ listet eine(!) Veröffentlichung in einem Open Access Journal auf. Das schaut sehr danach aus, als würde man sich da schlicht dem "pay to publish" verweigern und lieber auf Konferenzen fahren[1]. Das Peereview erfolgt ansonsten gerade live und öffentlich


[1] Für typische Gebühren beim Veröffentlichen kann man auch zur BlackHat fliegen und da präsentieren..

 

[Ned Flanders]

Das schaut sehr danach aus, als würde man sich da schlicht dem "pay to publish" verweigern und lieber auf Konferenzen fahren[

Was ja grundsätzlich sehr sympathisch ist. Vielleicht besteht ja Hoffnung dass sich das doch noch irgendwann durchsetzt. Bei uns wäre das aber komplett unmöglich. Schon von der habil Ordnung her.

 

[Colindo]

Der Publisher ist die Association for Computing Machinery, die sind etabliert. Der Rest ist wie @Piktogramm gesagt hat.

 

[cbtestarossa]

@Summerbreeze

Also kann man die ME / TPM whatever auch gleich deaktivieren so wie ich das sehe.
Was anderes was ich mich frage ist ob Signaturen überhaupt zu einer Sicherheit beitragen.
Zumindest gab es ja schon bei der Zwangsversignaturierung bei Firefox Addons die Debatte.
Und dann noch das Debakel mit den abgelaufenen Zertifikaten.
Also ich weiss nicht.