[English]Sicherheitsforscher haben eine Schwachstelle in den AMD Zen+ und Zen 2 CPUs aufgedeckt, die der Meltdown-Schwachstelle in Intel-Prozessoren gleicht. AMD hat einen Leitfaden zur Entschärfung der Sicherheitslücke erstellt und Details zur Funktionsweise der Schwachstelle veröffentlicht.
Anzeige
Ich bin über nachfolgenden Tweet auf den Sachverhalt aufmerksam geworden, der in diesem Artikel auf Toms Hardware erläutert wird.
Saidgani Musaev und Christof Fetzer von der Technischen Universität Dresden haben die Sicherheitslücke CVE-2020-12965 in AMD Zen+ und Zen 2 Prozessoren entdeckt. Im Oktober 2020 erfolgte eine Meldung der Schwachstelle an AMD, wobei dem Hersteller genügend Zeit eingeräumt wurde, eine Technik zur Schadensbegrenzung zu entwickeln. AMD hat die Schwachstelle aus der offiziellen Veröffentlichung auf Arxiv (PDF) übernommen und auf der AMD-Sicherheitswebsite beschrieben. Darin heißt es:
AMD hat die Schwachstelle CVE-2020-12965 "Transient Execution of Non-Canonical Accesses" (vorübergehende Ausführung nicht-kanonischer Zugriffe), die von einem Forscher eingereicht wurde, geprüft. In Kombination mit bestimmten Softwaresequenzen können AMD-CPUs vorübergehend nicht-kanonische Lade- und Speicheroperationen durchführen, wobei nur die unteren 48 Adressbits verwendet werden, was zu Datenlecks führen kann.
AMD empfiehlt Softwareanbietern, ihren Code auf mögliche Schwachstellen im Zusammenhang mit dieser Art der transienten Ausführung zu analysieren. Potenzielle Schwachstellen können durch das Einfügen einer LFENCE oder durch die Verwendung bestehender Spekulationsminderungstechniken, wie hier beschrieben, behoben werden.
Anzeige
Toms Hardware erwähnt hier, dass AMD letzte Woche Treiber-Patches für Ryzen-Chipsätze veröffentlichte, die die Zen+- und Zen 2-Architektur unterstützen. Dort wurde nicht explizit angegeben, was behoben wurde. AMD hat jedoch darauf hingewiesen, dass die Patches ein Problem im Platform Security Processor beheben. AMD teilte Toms Hardware aber mit, dass diese Patches nicht mit dem Transient Execution Bug in Verbindung stehen.
Ähnliche Artikel:
How To: BlueKeep-Check für Windows
Angreifer scannen Windows-Systeme auf BlueKeep-Lücke
Fast 1 Million Windows-Maschinen über BlueKeep-Schwachstelle angreifbar
BlueKeep: Wie steht's um die Remote Desktop Services-Schwachstelle CVE-2019-0708 in Windows
WannaCry-Reloaded? BSI-Warnung vor schwerer Remote Desktop Services-Sicherheitslücke in Windows
Sicherheitupdate für CVE-2019-0708 für Windows XP, Windows Server 2003, Windows Vista und Windows 7, Windows Server 2008/R2
Windows: Erste BlueKeep-Angriffe gesichtet
Neue Warnungen vor BlueKeep von Microsoft & Co.
Intel Vorschlag: SAPM-Protection (gegen Meltdown, Spectre)
Microsoft aktualisiert Meltdown/Spectre-Schutzseite
Meltdown/Specte und die verzögerte Offenlegung
Samsung Galaxy S7 von Meltdown-Schwachstelle betroffen
Windows 7/Server 2008 R2: Total Meltdown-Exploit verfügbar
Anzeige
Da sieht man es wieder, 100%ige Sicherheit gibt es nicht. Dürfte wenn überhaupt für Server Systeme ein problem sein, und kaum für Privat PCs.
iwie eine Art Trümmerspruch ('100%ige Sicherheit gibt es nicht')
– nat. gäbe es die, zumindest annähernd, wie auch in anderen Ind.-bereichen – und viel mehr, als aktuell!
Nur: es wird den Herstellern an dieser Stelle eben viel zu leicht gemacht!
Danke für den Beitrag, stimme zu das solche Aussagen fatalistisch sind. Die Wahrheit ist doch: Für solche Angriffe muss ich den Schadcode doch freiwillig ausführen, ja? Die Browser-Anbieter haben ja auch nachgebessert, das solche Angriffe auf den Speicher nicht mehr/sehr schwer funktionieren. Wo sonst als im Netz läuft potenziell schmutziges Javascript 24/7 im Browser?
Fall 2: Vier Kunden teilen sich eine VM in der Cloud, einer davon ist ein Angreifer. Die Lösung? Man muss sich dann halt in der Cloud einen privaten virtuellen Server anmieten. Kostet mehr, aber man teilt sich keinen RAM / keine CPU mehr mit potenziellen Angreifern.
Wann immer wir Code ausführen oder ein System mit anderen Nutzern teilen, mit blindem Gottvertrauen, dass dieser nicht schadhaft ist, nur dann gibt es keine 100% Sicherheit.
Es gab da eine schöne Story über einen verhassten IT-ler, der es geschafft hat, das in seine Firma nur signierte (!) Excel- und Word-Makros ausgeführt werden konnten. Die Moral war, Malware gehörte dort der Vergangenheit an. Er konnte sich zurücklehnen. Das Gros der Ransomware lädt Schadcode über versteckte Makros in Officedokumenten nach.
Wenn man einmal ein Makro selbst mit seinem Firmenschlüssel signiert hat merkt man auch, so schwer ist das nicht.
Schaut euch die Hauptangriffsvektoren auf Firmen an, dann wisst ihr, wo die wahren Lücken liegen. Bitweise Daten aus dem RAM mit akademischen Angriffen "rausprügeln" machen eher Unis oder Geheimdienste. Keine (Spear)Phisher.
Ja, sehe ich auch so. Wenn man sich z.B. die ganzen Sicherheitslücken der letzten Zeit anschaut, dann gibt es einfachere Wege einen Rechner zu übernehmen. Zum Beispiel mit der Admin-Maus, der Admin-Tastatur, Printing-Nightmare usw.
Relevant ist das für Server, wenn VMs verschiedener Kunden auf einem Blech laufen. Man weiß ja nicht was Leute auf so einer Miet-VM alles versuchen.
Ist natürlich Mist, weil die Migrationen Leistung kosten, was man eigentlich nicht möchte. Man sollte daher abwägen ob diese sehr speziellen Probleme für die eigene Umgebung hinreichend relevant sind.
Wenn man nur seine eigenen Server virtualisiert hat, dann spielt das eigentlich keine Rolle. Oder sagen wir mal so: Wenn ein Angreifer im Netz ist und das ausnutzen kann, dann liegt das Kind schon im Brunnen. Ich habe auch noch von keinem Fall gehört bei welchem Lateral Movement durch ein Netzwerk auf Grundlage von CPU-Lücken erfolgt wäre.
War doch nur eine Frage der Zeit, bis es auch die angeblich so sicheren AMD-CPUs trifft. Man muss halt einfach nur mal suchen, dann findet man auch dort genug. Den Privatanwender wird es – wie bei Intel – nicht kümmern. Die Wahrscheinlichkeit über solche Lücken angegriffen zu werden, ist extrem gering. Sonst wären die meisten PCs bereits außer Gefecht gesetzt. Im Privaten Umfeld habe ich jedoch von keinem einzigen Fall gehört.
Sicher ist etwas nur solange, bis es geknackt wird. Was Heute noch als Megasicher propagiert wird, ist morgen bereits unsicher und gehacked.
In Zeiten, wo die Software-Entwicklung unter großem Zeitdruck steht, wird halt nicht alles mögliche getan, um Lücken zu finden und zu schließen.
Wenn ich an das Drucker-Gemetzel von der letzten Monate denke, so kann eine Lücke durchaus 19 Jahre alt werden, ohne dass sie jemand bemerkt.
Die Komplexität der Systeme macht sie anfällig für Fehler, Lücken und Hacker. Es gibt keine 100% Sicherheit und die wird es wohl auch niemals geben. Das ist leider eine unumstößliche Tatsache. Nichtsdestotrotz finde ich, dass in der Entwicklung von Software wieder etwas mehr Zuverlässigkeit einziehen sollte.
Das ist schon klar. Ich wollte nur darauf hinaus, dass in Foren seit über 3,5 Jahren immer wieder propagiert wird, wie sicher die AMD CPUs doch seien und wie unsicher die Intel CPUs. Kaum einer wollte einsehen, dass sich die Forscher immer nur auf Intel gestürzt haben, weil sie dort das größte Medienecho erhofften. Wenn man aber auch mal die AMD-CPUs auseinander nimmt, wird man feststellen, dass sich in Punkto Sicherheit beide Hersteller wenig geben. Sicher sind sie nämlich beide nicht. Und wenn einer der beiden Hersteller in einer Sache etwas besser abschneidet als der andere, wird die Gesamtsituation für den nicht betroffenen Hersteller nicht automatisch besser.
Das Fatale ist, dass diese Lücke nur bei Epic und Ryzen, also den brandaktuellen Designs existiert, nicht aber bei vorigen CPUs. Dabei ist ja jetzt mit den ursprünglichen Spectre/Meltdown artigen Lücken und deren Varianten seit rund 5 Jahren grundsätzlich klar, wie solche Lücken entstehen und ausgenutzt werden. Um so beschämender, dass AMD solche Lücken bei den aktuellen Designs nicht verhindert hat. Beschämend auch, dass es nun anscheinend nur Compiler und Software-Updates richten sollen, und scheinbar nicht per Microcode behoben werden kann.
Warum ist das für AMD beschämend? Das CPU design von ryzen stand vor der Veröffentlichung von meltdown/Spectre fest.
Und das Angriffszenario ist deutlich kleiner als bei Intel.
Siehe auch die Formulierung bei Heise:
https://www.heise.de/news/CPU-Sicherheitsluecke-AMD-Ryzen-und-Epyc-per-Seitenkanal-verwundbar-6178386.html
Von das Thema im headliner auch überall auch mit den clickbait triggerwort Meltdown versehen.
Sorry Herr Born, auch hier…