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

DevPandi schrieb:
In dem Fall, weil sich die Schadsoftware in den Bausteinen im Mainboard "einnisten" kann
Das muss sich ja nicht nur einnisten, sondern das auf eine Art machen, dass es bei einem Kaltstart automatisch wieder gestartet wird: Da sind die Möglichkeiten überschaubar und welche davon wird nicht von einem CMOS-Clear gelöscht?

Also PC runterfahren, Stromstecker ziehen, die CMOS-Bat (die gar keine Batterie ist, sondern eine Primärzelle) für eine Stunde raus, dann gleich ein definitiv nicht infiziertes (da read-only) Livesystems booten (also kein Ubuntu mit persistenter Datei - oder wie man das nennt) und "sudo blkdiscard -vf …" über die SSD(s).

Wo soll es dann noch sein?

Schwieriger wird es eher, eine nicht infzierte Sicherung zu finden, damit es nach der Wiederherstellung nicht gleich wieder da ist.
 
ElliotAlderson schrieb:
Ihr erwartet doch nicht ernsthaft, dass 20 Jahre alte Hardware geupdatet wird?
Kann AMD da nachvollziehen. Über die 6 Jahre kann man streiten, aber ich hätte das auch nicht für alle gebracht. Die wollen auch Geld verdienen.
Wer spricht denn darüber?
Es geht doch eher darum, dass Zen2 im Desktop nicht mehr geupdated wird. Das sind seit Release ziemlich genau 5 Jahre. Wenn man noch berücksichtigt, dass z.B. die aktuellen Konsolenchips Zen2 verwenden und ja offensichtlich Notebookchips bis zur 3000er Reihe (Zen+) mit Patches bedacht werden, sowie obendrein Threadripper 3000 (Zen2), dann ist das schon ziemlich fragwürdig, dass bei den Desktop Chips bei Zen 3 Schluss ist.
 
  • Gefällt mir
Reaktionen: CyrionX und Erenxbo
Eletron schrieb:
MSI B450 Tomahawk Max. Vor ein paar Tagen wurde CVE-2024-36877 gefixt, das scheint allerdings was anderes zu sein.
Bei meinem steht es dabei, warum bei deinem nicht - ka fix.png
 
Caramon2 schrieb:
Also PC runterfahren, Stromstecker ziehen, die CMOS-Bat (die gar keine Batterie ist, sondern eine Primärzelle) für eine Stunde raus, dann gleich ein definitiv nicht infiziertes (da read-only) Livesystems booten (also kein Ubuntu mit persistenter Datei - oder wie man das nennt) und "sudo blkdiscard -vf …" über die SSD(s).
Wird dir an der Stelle nicht viel bringen, weil die heutigen Bausteine keine „ROMs“ mehr sind und auch ohne Stromzufuhr relativ lange die Werte behalten.

Batterie raus triggert heute die Funktion, die Werte zurückzusetzen. Ist aber nicht mehr für deren Erhalt notwendig.
Caramon2 schrieb:
Da sind die Möglichkeiten überschaubar und welche davon wird nicht von einem CMOS-Clear gelöscht?
Der gesamte Baustein in dem das UEFI geflasht wird.
 
  • Gefällt mir
Reaktionen: M-X, Zarlak und Caramon2
Neodar schrieb:
Kein guter Move von AMD. Es wirkt so, als würde man sich nicht besonders für dieses Sicherheitsproblem interessieren.
Ryzen 3000 ist weiterhin sehr verbreitet.
Vielleicht weil es in der Praxis überhaupt kein Problem ist? Der Angreifer muss zuerst den OS Schutz umgehen und erst dann kann er diese Lücke theoretisch ausnutzen.
 
Ich denke mal bei genug Gegenwind und Protesten wird AMD auch die 3000er Patchen.
 
Scotty40 schrieb:
Bei meinem steht es dabei
Ich denke, weil das, was gefixt wurde, nur eine Lücke ist, die MSI Boards betrifft. Daher habe ich nur eine geringe Hoffnung, was mein Board betrifft.
 
Zuletzt bearbeitet:
Mracpad schrieb:
Also das schon die 3000er CPU kein Update bekommen, hinterlässt schon n ziemlich miesen Geschmack.

..., macht aber insgesamt als AMD Kunde trotzdem schlechte Laune.
Aber nur wenn man bei jeder Nachricht direkt in Panik ausbricht ohne überhaupt darüber nachzudenken was im Vorfeld schon alles gelaufen sein muss bis die entsprechende Sicherheitslücke ausgenutzt werden kann.
 
JustAnotherTux schrieb:
Vorallem weil vermutlich kein Fix auf Betriebssystemebene möglich sein wird.
Bei Meltdown und Spectre wurden ja auch Workarounds auf Betriebssystemebene und teiweise auch Anwendungsebene umgesetzt bzw. waren möglich.

Bei dieser Sicherheitslücke wird es wohl nur über die Firmware möglich sein.

Umgekehrt: Spectre und Meltdown sind grundlegende Hardware-Bugs, die Funktionen betreffen, die man ueber Firmware nicht loesen kann bzw. will (weil man da z.B. die komplette Sprungvorhersage abschalten muesste, was, falls es ueberhaupt moeglich ist, die Prozessoren um einen Faktor >2 langsamer machen wuerde). Daher hat man dann den Weg gewaehlt, dass ausgewaehlte Software (Betriebssystem-Kernel, Browser) mit viel Programmieraufwand dagegen abgesichert wird, und die Hardwarehersteller geben denen ueber Firmware-updates ein paar Werkzeuge in die Hand, um das zu machen.

Die allermeiste Software ist aber immer noch anfaellig, und das redet man sich damit schoen, dass die Daten, die von dieser Software verwaltet werden, nicht so kritisch sind und dass zumindest Spectre die Daten nur relativ langsam extrahieren kann (Meltdown ist da um mehrere Groessenordnungen schneller). Und weil die Abwiegelungsstrategie so gut funktioniert haben, bringen AMD, Intel, ARM, Apple, und Qualcomm auch im Jahr 2024 (7 Jahre nachdem AMD und Intel von Spectre erfahren haben) noch immer CPUs auf den Markt, die fuer Spectre anfaellig sind, und kaum welche (ein paar low-end-ARMs), die dafuer nicht anfaellig sind. Wenigstens Meltdown haben sie inzwischen gefixt, bzw. (AMD) von Anfang an nicht eingebaut. Und dabei erscheinen schon seit Jahren Artikel ueber "Invisible Speculation", die zeigen, wie man Spectre in Hardware fixen kann und die resultierende Hardware aehnlich schnell ist wie die Spectre-anfaellige Hardware.

Jetzt zu Sinkclose: Das betrifft eine Funktion (SMM), die vor allem ueber Firmware implementiert ist, daher kann man die Luecke auch ueber Firmware schliessen. Und die meiste Software kriegt vom SMM nichts mit (das ist ja auch der Sinn des SMM), daher kann und braucht man auch an der Software nichts machen.

Dass die Hardwarehersteller bei Spectre das Problem auf die Softwarehersteller abschieben, und bei Sinkclose ein Fix ueber Firmware moeglich ist, ist kein Anzeichen dafuer, dass Sinkclose schwerwiegender ist. Wenn ueberhaupt, dann im Gegenteil. Aber das ist kein eindimensionales Problem, bei Sicherheitsluecken ist immer die Frage, wie leicht ein Angriff bei welchem Angriffsszenario moeglich ist, ob das Angriffsszenario fuer den potentiell Angegriffenen eine Rolle spielt, wieviel Verteidigungsmassnahmen kosten, und sicher noch andere Dinge, die ich vergessen habe.

Und die Sachen stehen auch nicht im leeren Raum. So koennte ein Angreifer, der keine leichtere Luecke findet, eine Luecke in der Kernelabsicherung gegen Spectre ausnutzen, um Zugriffsdaten fuer den Root-Account aus dem Kernel zu extrahieren, damit dann zu root werden, als root dann einen Treiber installieren, der dann mittels Sinkhole ein Backdoor dauerhaft im SMM hinterlegt, das auch noch dann wirkt, wenn die Luecke in der Kernelabwehr gegen Spectre geschlossen ist.
 
  • Gefällt mir
Reaktionen: CyrionX
Bei Notebook-CPUs wird Ryzen 3000 allerdings noch mit einem Fix bedacht.

Phew, vermutlich habe ich noch einmal Schwein (mit meiner 4000er APU) gehabt, wenn es dabei bleibt und diese noch einen Patch/Fix für Sinkclose bekommt.
 
1ST1 schrieb:
Jetzt stellt sich mir aber die Frage, wo ist die Schadsoftware denn gespeichert, wenn sie sogar eine Systemneuinstallation überlebt?

Im Flash der UEFI z.B.; vielleicht da auch nur ein kleiner Teil, und der Rest irgendwo auf der SSD, an einem Platz, der freigeschaufelt wurde, indem etwas anderes komprimiert wird. Aber wenn der Benutzer dann nach diesen Inhalten fragt, greift das SMM ein und zeigt den urspruenglichen Inhalt.

Und die zweite Info, die ich vermisse, wie kann sie mit ihrem "Herrchen" kommunizieren? Netzwerke sind sehr individuell, haben evtl kein DHCP (insbesondere Server!), direkter Internetzugang ist auch nicht immer möglich (Proxy!), das Ding hat keine Chance nach einem WLAN-Passwort zu fragen und so ziemlich jedes verschiedene PC Modell hat eine andere Netzwerk/WLAN-Karte, daher ist an dem Speicherort so viel Platz für so viele Netzwerkkarten-Treiber, dass es überhaupt eine Verbindung aufbauen kann und wie überwindet "es" die anderen Hürden?

Einfach im entsprechenden Bereich im Kernelspeicher nachschauen, wie Netzwerkpakete nach aussen gesendet werden, und es dann genauso machen. Klar, wird nicht auf jedem System funktionieren, aber es reicht ja, wenn's auf dem angegriffenen System funktioniet.
 
Tomsenq schrieb:
Der Angreifer muss zuerst den OS Schutz umgehen und erst dann kann er diese Lücke theoretisch ausnutzen.

Was sicherlich früher oder später passieren wird. Da schiebt AMD die Schuld dann auf MS, nicht sehr schön.

Ich habe auch noch ein 3000er und ich muss sagen da ist Intel besser unterwegs was Meltdown und co. angeht. Da sollte sich AMD eine Scheibe abscheiden. Ich verstehe es halt nicht weil das doch kaum Kosten für AMD verursacht aber ein totaler PR-Gewinn wäre...
 
Lurandil schrieb:
Sind diese nun betroffen oder nicht? Bei einem unserer Söhne werkelt ein Ryzen 5 2600 im Gaming-PC.

Ja, aber schon EoL daher keine Info dazu.
 
Verstehe ich das richtig: Wenn ich bei einem Spiel einen Anticheat habe (LoL z.B.), dann kann mir sowas passieren?
 
Dito schrieb:
kann mir sowas passieren?
Die Frage ist, wie hoch die Wahrscheinlichkeit ist. Allerdings liegt das im Bereich des Möglichen. Das betrifft auch Treiber oder andere Software, die Kernelzugriff benötigt. Beispielsweise HW-Info.
 
  • Gefällt mir
Reaktionen: Tanzmusikus
DevPandi schrieb:
Batterie raus triggert heute die Funktion, die Werte zurückzusetzen. Ist aber nicht mehr für deren Erhalt notwendig.
Willst du damit sagen alle Mainboardhersteller bauen die Batterie nur noch zu dem Zweck ein, beim rausnehmen selbiger einen CMOS reset zu triggern? Hast du dazu eine Quelle? Kann ich ehrlich gesagt nicht wirklich glauben. Das ginge mit deutlich weniger Aufwand deutlich komfortabler, so wie es einige Boards per Schalter am I/O Panel bereits vormachen.
 
Frage: Behebt der Fix nur die Sicherheitslücke bevor man eindringen kann oder wird dadurch auch ein evtl. bereits vorhandener Zugriff blockiert? Kann man also, da man i.d.R. nicht sagen kann, ob man betroffen oder nicht, hinterher sicher sein, dass das System diesbzgl. in jeder Hinsicht sicher ist?
 
Zurück
Oben