Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsSicherheitslücke: Sinkclose betrifft alle AMD-CPUs seit fast 20 Jahren
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.
1. Was würdest do noch unter "heutige" einordnen, schon ab Zen 1 oder schon weit darunter?
2. Im Artikel steht, dass im Notebooksegment CPUs ab Ryzen 3000 bedacht werden, was dann ja bedeutet ab Zen+.
Oder war hier eher Zen 2, also eigentlich die 4000er Reihe gemeint?
@Capthowdy
Das hat er nicht geschrieben. Die Batterie wird bspw. für die Onboard-Uhr benötigt, damit sie weiterläuft, auch wenn der Rechner aus ist.
Für das Speichern der BIOS-Einstellungen wird sie aber nicht mehr benötigt.
Das nicht, da hilft nur das Entsorgen der Hardware. Da aber eigentlich keiner mitbekommt das er betroffen ist, ist das auch nicht notwendig. Pauschal entsorgt ja deswegen keiner vorzeitig seine Hardware.
Genau, das UEFI als auch deren Werte werden heute in einem NAND-Baustein auf dem Mainboard gesichert und benötigen die CMOS-Batterie eigentlich nicht mehr. Früher war das BIOS in einem ROM und die Werte wurden im besagten CMOS gesichert, der eine konstante Stromzufuhr benötigt.
Früher war es daher auch quasi unmöglich ein "BIOS-Update" auf ein Mainboard aufzuspielen, es musste dafür der ROM getauscht werden. Heute durch den NAND ist das möglich.
Die Batterie versorgt heute primär nur noch die interne Uhr des Mainboards, da sich diese sonst nicht weiter läuft und quasi jedes mal zurück gesetzt werden muss.
Der Hauptgrund der Batterie ist wohl eher, die RCT (real time clock) am laufen zu halten, sodass das Gerät die aktuelle Zeit kennt. Weil wie soll das sonst gehen?
Es gibt natürlich auch Geräte ohne RTC bzw. zwar mit RTC, aber ohne Batterie (Raspberry Pi bspw. hat entweder keine oder nur die Schaltkreise ohne Batterie, die man zusätzlich stecken muss)
-> zwingend Notwendig ist das zwar nicht, da bei laufendem System und Stromzufuhr sich die aktuelle Zeit auch via NTP und Co. holen lässt. Aber spätestens wenn Dinge wie automatisches Booten zu Zeit xyz möglich sein soll, braucht es die Batterie.
Aber ja, @DevPandi hat dahingehend recht, in aktuellen Umsetzungen benötigt man die Batterie nicht mehr für das Vorhalten einer Spannung um die Daten im Speicher verfügbar zu halten.
Wie sieht es aus, wenn BIOS Hersteller keinen FE Patch anbieten, gibt es dann auch Möglichkeiten?
Wenn das System schon befallen ist, nützt ein Patch dann noch was?
Sind Linux Nutzer gleichermaßen betroffen (ich denke mein, weil Ring 0).
VT Beitrag: wie wahrscheinlich ist ein gewollter Backdoor Zugriff für NSA und Co nach 9/11? Da das so komplex ist, wäre es ja nicht undenkbar. Und nun aufgeflogen, also wird gefixt bevor es Schaden bewirkt.
Firefly2023 schrieb:
Aber die Deutschen lieben ja "Panik". Dann macht euch halt verrückt. Wie gesagt ich nehme die alten AMDs und MBs gerne.
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.
Das ist btw. von der Denkweise her falschrum. Denn wie willst du den OS Schutz garantieren bzw. dich darauf stützen, wenn du gar nicht garantieren kannst, dass das System mit DEINEM OS benutzt wird?
Der Witz dabei ist, das ist im Grunde einer der Hauptgründe warum Konzerne wie Microsoft so auf UEFI mit SecureBoot rumreiten. Es gibt einen enorm hohen Angriffsvektor, wenn ein potentieller Angreifer physischen Zugriff an das System hat und das System einfach ein vom ihm verwaltetes OS lädt, wo er dann volle Rechte hat. Nürlich ist es aus Sicht des Endanwenders eine Art Gängelung, wenn ein Dritter vorschreiben will, wie das Ding zu booten hat. Aber Vorfälle wie dem hier in der News gemeldeten zeigt, dass die komplette Kette abzusichern ist. Schon ein Teil was nicht aufgeht, und das ganze Sicherheitskonzept platzt...
Die BIOS-Batterie (eine 3V CR2032 Knopfzelle) wird erst dann benötigt, wenn das Netzteil aus der Steckdose ausgesteckt wird, weil das BIOS ansonsten über die immer anliegende 5V Standby Spannung des Netzteils versorgt wird.
Ein ClearCMOS oder ein BIOS-Update bringt hier ebenfalls nichts, da bei einem Update lediglich die Bereiche im Speicherchip überschrieben werden, die das eigentliche BIOS enthalten, alles andere dort drin bleibt unangetastet.
Man wird Sinkclose auf diese Weise nicht los, egal was man sich sonst noch ausdenkt.
Vor allem im Notebook Umfeld ist das seit 10+ Jahren üblich.
Seit mindestens den Anfängen von UEFI Systemen ist es bei brauchbarer Umsetzung bspw. nicht mehr möglich, einfach die Batterie zu ziehen um das Bios/UEFI PW zu löschen. Das konnten viele Notebooks länger schon als es UEFI gibt.
Das ganze hat aber auch eine Kehrseite. Denn was über entsprechende Rechte "rein" geschrieben werden kann, kann häufig mit entsprechenden Rechten einfach überschrieben werden, wenn man weis wo was steht. Die Frage ist eher, ob man bei einem Befall auf der Ebene überhaupt erkennt, ob etwas befallen ist.
Helge01 schrieb:
Na wenn dem so ist kannst du sicherlich eine Menge an Linux Schadsoftware aufzählen.
Bitte aber nicht die bisher bekannten (Sicherheitslücken sind != Malware)
Worauf willst du hinaus?
Du willst einerseits keine "bekannten" Dinge aufgezählt haben aber verlangst andererseits eine Liste von Schadsoftware? Welche soll das sein wenn sie doch nicht bisher bekannt sein darf?
Das nicht, da hilft nur das Entsorgen der Hardware. Da aber eigentlich keiner mitbekommt das er betroffen ist, ist das auch nicht notwendig. Pauschal entsorgt ja deswegen keiner seine Hardware.
Das heißt, daß z.B. Juristen, Mediziner, Journalisten und Ermittler, die auch daheim mit sensiblen Daten arbeiten werden, ihren kompletten PC oder Laptop mit einer AMD-CPU entsorgen müssen, nur um sicher zugehen, daß trotz neuer Firmware keine Informationen abgegriffen werden können, selbst wenn deren Computer nicht infiziert waren?
Gibt es denn wirklich keine Option, über die Firmware oder ähnliche Alternativen auf sogenannte "Werkseinstellungen" aller Komponenten zurückzusetzen oder ein Programm zu entwickeln, was wenigstens eine Infizierung und Kompromittierung anzeigen kann(siehe Hausratversicherung)? Weil das, was AMD i.M. als Option anbietet, kann ja wohl kaum als sichere und solide Lösung angesehen werden?
Die Liste ist die Gegenwart, mehr gibt es bis zum heutigem Zeitpunkt nicht. Deswegen solltest du ja uns mal die Menge an aktueller Malware für Linux mitteilen.
Und nochmal um Missverständnisse vorzubeugen, Sicherheitslücken sind != Malware.
Ergänzung ()
p.b.s. schrieb:
Gibt es denn wirklich keine Option, über die Firmware oder ähnliche Alternativen auf sogenannte "Werkseinstellungen" aller Komponenten zurückzusetzen oder ein Programm zu entwickeln, was wenigstens eine Infizierung und Kompromittierung anzeigen kann(siehe Hausratversicherung)?
"Gibt es nicht", weil es bisher noch nicht relevant war, oder weil es schon von vornherein unrealistisch ist, dafür z.B. ein spezielles Programm zu entwickeln, weil es technisch nicht möglich ist?
