News Sicherheitslücke: Sinkclose betrifft alle AMD-CPUs seit fast 20 Jahren

Ending software support for older products is standard practice in the fast-moving tech industry, AMD is not unique in this regard. While the issue only affects seriously breached systems, AMD prioritizes security. We believe our mitigation's available today are an appropriate response to the threat.
AMD
Die nächste Plattform kommt bei mir mit sehr hoher Wahrscheinlichkeit nicht mehr von AMD:
  • Firmware Updates für B450 mit Unterstützung für Zen 3 erst nach Shitstorm
  • haben PCIe 4.0 für B450 verhindert
  • Jetzt kein Update für meinen Ryzen 2600

Ich bin mir aber sicher, dass bei AMDBase sicher Gründe gefunden werden, warum AMD trotzdem viel toller als Intel ist.
 
  • Gefällt mir
Reaktionen: ElliotAlderson und Der_Rolf
Gerade mal bei meinem Board nach einem aktuellen BIOS geschaut und eine neue Version von vor 5 Tagen entdeckt und da steht
  • Beschreibung:
    - Fixed CVE-2024-36877 security issue.

Was ist denn das für ein Problem, wenn doch das hier beschriebene Problem ein ganz anderes ist:
AMD hat eine entsprechende Informationsseite für den CVE-2023-31315 veröffentlicht und führt Sinkclose unter der ID AMD-SB-7014.
 
@nöörd
Warte erst mal ab, was vielleicht noch an neuen Ankündigungen kommt.

Und auch wenn ich AMD nie als Heilsbringer gesehen habe: Der Shitstorm bzgl. der Zen 3 - Unterstützung der ersten beiden AM4-Chipsatz-Generationen konnte ja nur deswegen Erfolg zeitigen, weil er grundsätzlich beim Plattformdesign tatsächlich so berücksichtigt wurde. Die BWLer hatten dann mal vorübergehend die Oberhand.
 
SavageSkull schrieb:
Gerade mal bei meinem Board nach einem aktuellen BIOS geschaut und eine neue Version von vor 5 Tagen entdeckt und da steht
Der CVE-2024-36877 hat zwar auch etwas mit dem SMM zu tun, betrifft aber nur eine Buffer Overflow Lücke in der Firmware von MSI. Und die CVE betrifft nicht spezifische CPUs, sondern generell Boards von MSI, egal ob Sockel AM4, AM5 oder die von Intel mit den CHipsätzen 300 bis 700.

https://jjensn.com/at-home-in-your-firmware/
 
  • Gefällt mir
Reaktionen: SavageSkull und ComputerJunge
@SavageSkull
Das entsprechende AMD Pendant dieser Funktion heißt Guest-Mode Execute Trap (GMET) wie auch unter dem verlinkten Artikel erwähnt. Nach diesem Artikel und auch allem was ich sonst noch so im Internet gefunden habe, wird GMET aber erst mit Zen 2 unterstützt, was somit nicht erklärt weshalb Zen+ Prozessoren / Ryzen 2000 unter Windows 11 unterstützt werden aber Zen 1 / Ryzen 1000 nicht. Ich muss allerdings auch zugeben, dass ich (erschreckenderweise) keine Quellen zu dem Thema gefunden habe, die ich als vertrauenswürdig einstufen würde.
 
Zuletzt bearbeitet:
tso schrieb:
Ich muss allerdings auch zugeben, dass ich (erschreckenderweise) keine Quellen zu dem Thema gefunden habe, die ich als vertrauenswürdig einstufen würde.
Etwas merkwürdig, dass wenn es so ist, dass nicht so von Microsoft kommuniziert wurde und von diversen Techseiten richtig gestellt wurde.
Stattdessen bekommt Microsoft einfach wieder mal Hate, weil es für die User aussieht, als ob hier einem die Nase nicht passt.

@Jan Vielleicht könntet ihr zu dem Thema auch mal nachforschen und richtig stellen, ob oder ob es nicht so ist.
Siehe Post #403
 
mibbio schrieb:
der den SMM mal genauer beleuchtet
Deeply embedded Backdoor. Da ist keine Sicherheitslücke bekannt geworden, es hat nur jemand durch Zufall den Schlüssel gefunden. Gut das alle Prozessoren der letzten 20 Jahre den Schmarrn haben. Sogar Via:
 
  • Gefällt mir
Reaktionen: [SM]Valen, Ben99 und Firefly2023
Verstehe nicht wie manche Leute so pisst sein können?
Keine Frage die Situation ist alles andere als schön aber auch recht überschaubar für den "Normalo User" vor allem wenn man das hier berücksichtigt.
Bevor es um die eigentliche Sicherheitslücke geht, muss klargestellt werden, dass zum Ausnutzen dieser Sicherheitslücke ein vorheriger erfolgreicher Angriff auf das Betriebssystem und dessen Kernel stattgefunden haben muss. Angreifer müssen sich Berechtigungen für den Ring 0 verschaffen.
Wenn es soweit kommt ist eh schon alles verloren.
Wie wenn man sagen würde als die Hindenburg damals 30 Meter über dem Boden Feuer gefangen hat. Hätte jeder damals einen Fallschirm gehabt wäre keiner gestorben. Keine Fallschirme für jedermann war eine Sicherheitslücke im Konzept der Zeppelin Luftfahrt.

Das Problem bei diesen Sicherheitslücken ist immer die Software weshalb sie sich auch nahezu immer durch Software bzw. Microcode Update fixen btw. abmildern lassen.
Deswegen sollte man die Hardware nicht immer gleich abschreiben.
 
  • Gefällt mir
Reaktionen: Firefly2023
Firefly2023 schrieb:
Nö. AMD schreibt selber, dass es dazu physichen Kontakt zum Rechner braucht
Nein, das schreibt AMD nicht. Ein gut getarnter Treiber oder Lücken in Systemprozessen reichen aus. Das erste Tor ist kernel-level access und es ist nicht so, dass genau das in Vergangenheit kaum genutzt wurde (z.B. durch eine Lücke im Windos App-Locker, ausgenutzt durch Lazarus (nordkoreanische Hacker) ).

Firefly2023 schrieb:
Der HAcker braucht Zugriff auf den PC oder Server, steht im Artikel.
Genau, und das bedeutet nicht, dass der Angreifer dafür physisch vor deiner Kiste präsent sein muss.

ChrisMK72 schrieb:
Ist da nicht zusätzlich zu dieser Lückenschließung nicht erstmal diese Vorbedingung zu verhindern?
Und wenn diese nicht verhindert wurde, ist es eh egal. ;) Denn dann is ja sowieso schon jemand in deinem System.
Das erste ist Richtig. Die Vorbedingung ist, dass man bereits Zugang zum System hat (SMM). Aber dass jeder weitere Schritt danach dann "eh egal" wäre ist nicht zu Ende gedacht, denn der Unterschied ist, dass du ja nichts davon wissen kannst, OB es denn schon soweit gekommen ist, weil aktuell so gut wie nichts dieses Eindringen erkennen kann. Genau deshalb triffst du aus heiterem Himmel auch keine Gegenmaßnahme, denn für dich scheint die Welt in Ordnung.

Hellyeah schrieb:
Ich hab noch nicht ganz verstanden wo der Schadcode denn dann gespeichert sein soll.
Physikalisch in den Speicherregionen, wo beispielsweise die Firmware des Mainboards, der Grafikkarte, des SSD Controllers etc. hinterlegt ist.

Zur Bereinigung im Allgemeinen:

Theoretisch ist es möglich, den bereits eingenisteten Schadcode zu entfernen, ohne zu wissen, wie und wo er hinterlegt ist. Dazu müsste aber jedes physikalisch am Mainboard angeschlossene Gerät mit einer vom Hersteller zur Verfügung gestellten Firmware, die nicht nur die genutzten, sondern auch ungenutzten Speicherbereiche mit Soll-Werten beschreibt (Init lässt grüßen). Das Problem an der Sache ist nur, dass genau dafür jene Privilegien benötigt werden, die man gut schützen möchte. Das andere Problem ist, dass das kaum während des laufenden OS-Betriebs machbar ist. Das ist ungefähr so, als würde man während der Autobahnfahrt den Keilriemen wechseln wollen.
 
  • Gefällt mir
Reaktionen: ElliotAlderson, p.b.s., Lurandil und eine weitere Person
ghecko schrieb:
Gut das alle Prozessoren der letzten 20 Jahre den Schmarrn haben.
Sogar noch deutlich länger. Denn eingeführt wurde der SMM prinzipiell von Intel mit dem 80386, nur war der damals noch nicht so umfangreich/komplex wie in den späteren CPUs. Der SMM wurde ja immer mehr erweitert.
 
  • Gefällt mir
Reaktionen: mae
Zum Artikel Update: Also ich kann mich entsinnen, dass intel da schon weiter zurückgegangen ist um Sicherheitslücken zu schließen und so schnelllebig ist die Branche nicht. Ein Ryzen 2000 oder 3000 wird halt noch leicht 5 Jahre benutzt, bevor den irgendwer wegschmeißt. Die Ausrede ist schon ne Frechheit und zeigt eigentlich nur, dass es einem nichts daran liegt langlebige Produkte zu schaffen.
 
  • Gefällt mir
Reaktionen: Moon44, mae, Tobi-S. und eine weitere Person
Wie war der Tenor von AMD? Der AM4-Sockel wird mit weiteren Neuheiten versorgt?

Für das berühmte Protokoll: Im Büro werkeln AMDs 2400GE und 3400GE und bei mir daheim die Brüder dieser CPUs ebenso.

Es lebe der noch problemlos nutzbare Elektroschrott !?!


Wo sind die Kinder der Fridays for Future? Einfach mal nach China reisen und dort Sitzblockaden und Klebenaktionen durchführen ^^
 
Zuletzt bearbeitet: (rechtschreibung)
Mein MSI X570 Unify und B450 Gaming Plus Max bekamen schon die BIOS-Updates (09.08.24) inkl.Sinkclose-Fix, mein B550M Phantom Gaming 4von ASRock hat (noch) nichts.

//Edit: Quatsch, ist "nur" https://jjensn.com/at-home-in-your-firmware/
 
Zuletzt bearbeitet:
t3chn0 schrieb:
Hersteller Garantie auf die Fahrzeuge geben. Irgendwas zwischen 2-5 Jahre und das bei brandneuen Fahrzeugen
Kia 7 Jahre :) im allgemeinen , es geht auch besser :)
Mensch_lein schrieb:
Kurz gesagt, die Problematik ist nicht nix, das meine ich gar nicht, aber sie ist nicht so gravierend, wie manche hier tun

Denke ich auch das selbe wie bei Intel im Prinzip vor 2 Jahren oder so , aber Restrisiko gibt es immer , sicher gibt es da draussen Menschen die diese Lücke für irgendein Spezialfall missbrauchen könnten , soweit können wir gar nicht um die Ecke denken auf was manche Menschen für Ideen kommen

Aber den sehr speziellen Fall Mal ausgenommen gibt es wohl einfache Methoden Rechner zu Kapern
 
  • Gefällt mir
Reaktionen: Alesis
Ripcord schrieb:
Gleich den ganzen PC ausmisten ist doch übertrieben, wo kann sich denn sowas auf Dauer einnisten?
Nein, hat man im Bundestag meine ich auch in Teilen gemacht...
 
Zumindest alle CPUs bis Zen+(April 2018, Zen hat einfach zuviele Hardware-Bugs die in Zen+ gefixt wurtden) sollten ein Mainboard-Update bekomen. Ob wieder auch die Hersteller sich quergestellt haben? Ist nicht das erste Mal das die Mainboards-Hersteller sich quer stellten und doch nachträglich AMD ein Update bereitstellte und die widerwillig es auslieferm.
 
Fegr8 schrieb:
Ob wieder auch die Hersteller sich quergestellt haben? Ist nicht das erste Mal das die Mainboards-Hersteller sich quer stellten und doch nachträglich AMD ein Update bereitstellte und die widerwillig es auslieferm.

Wenn die das ueber das Betriebssystem ausliefern wuerden, waere schon einmal der wohl wichtigste Angriffspfad geschlossen, und damit wuerde AMD wohl auch viel mehr Geraete erreichen als ueber BIOS-Updates (die aber zum Schliessen anderer Angriffspfade trotzdem sinnvoll waeren). Dass Microsoft oder die Linux-Entwickler etwas dagegen haben, einen Blob durch einen anderen zu ersetzen, um eine Sicherheitsluecke zu schliessen, bezweifle ich. Also liegt die Schuld bei AMD.
 
  • Gefällt mir
Reaktionen: Unnu
Habe einen 3800X, dafür gibts keinen Fix.
Aber AM4 wird weiter mit Neuerscheinungen Supportet, mal Nachdenken ob ich wohl auf mein 5 Jahre altes Board dann ne neue CPU mit minimal mehr Power schraube.
Hab schon nachgedacht, nee mach ich nicht.
Super Elektroschrott was verhindert werden könnte.
 
PiraniaXL schrieb:
Fakt ist, der typische "Mediamarkt-Kunde" wird nie was von dieser Schwachstelle erfahren geschweige was dagegen tun.
… oder müssen.

Leutz, das Dingen ist spannend für Spooks, aka Geheimdienste und andere interessierte Kreise.
Weil damit, ggf. / möglicherweise, wenn geschickt vorgegangen wird, eine Malware persistent und Hardwarenah platziert werden kann.

Der Aufwand ist immens, das lohnt überhaupt nur bei wirklich spannenden Zielen, wie Regierungen, Forschung etc.
… Cloud RZ, also Hyperscaler … das könnte lohnen.
Wie‘s mit der Zuverlässigkeit aussieht hat auch noch keiner erzählt. Bis auf den Hinweis eines Forschers. Und der sagt, das war das komplizierteste überhaupt, was er bisher je getan hat.

Da ist es wahrscheinlich weitaus einfacher direkt einen manipulierten Baustein draufzulöten. Und weniger Fehleranfällig. Und Geräuschärmer. Und zuverlässiger.
Und billiger.
Oder man erpresst direkt einen Mitarbeiter.
Oder man schleust über Monate einen Spion ein.

Und selbst wenn, ich muss ja erstmal wieder rauskommen aus dem Rechner.
DAS ist dann wieder eine komplett andere, neue Geschichte.

Dann muss er erstmal wieder Root werden.
Und zwar nicht nur für diesen Rechner, sondern für‘s Netz. Den muss er erstmal bekommen. Dann möglichst unauffällig solange durchhangeln, bis ich irgendwo eine Tür nach draußen öffnen kann. Am besten unbemerkt.
(Wie das funktionieren soll, bei einem einigermaßen brauchbar aufgebauten SOC
- mitsamt vernünftig konfigurierter IT - hat mir auch keiner erklären können.)

Mir sind schon viele, viele Angriffsszenarien untergekommen.
Alle, ohne Ausnahme waren entweder veraltete IT, schlampiges Patchmanagement, idiotische Struktur, oder das SOC hat gepennt. Meist eine Kombination aus obigen Gründen.

Das Ding würde ich gerne mal ausgeführt sehen „in the wild“.
Wird mir vermutlich nicht vergönnt sein in meinen noch verbleibenden 20 Jahren.

Kurz:
Theorie == WOW!
Praxis == Ahja, na dann. Behalten wir mal im Hinterkopf.
 
  • Gefällt mir
Reaktionen: Firefly2023 und Sorb
Zurück
Oben