TakeAway-Sicherheitslücke in AMD-CPUs seit 2011

[Phantomias88]

Ja wie immer, wie reden aneinander vorbei.

BTW, die Kern-Isolierung Funktioniert nicht mehr bei mir.

Die Speicherintegrität ist eine Funktion von Windows, die sicherstellt, dass Code, der im Windows-Kernel ausgeführt wird, sicher entworfen und vertrauenswürdig ist. Es verwendet die Hardware-Virtualisierung und Hyper-V, um Windows-Kernelmodus-Prozesse vor der Injektion und Ausführung von böswilligen oder nicht überprüften Codes zu schützen. Die Integrität von Code, der unter Windows ausgeführt wird, wird durch die Speicherintegrität überprüft, wodurch Windows gegen Angriffe durch bösartige Software resistent ist. Die Speicherintegrität ist eine leistungsfähige Sicherheitsgrenze, die dazu beiträgt, dass viele Arten von Malware in Windows 10-und Windows Server 2016-Umgebungen blockiert werden.

Core isolation - Microsoft Support

docs.microsoft.com

Na dann verzichten wir eben auf Virtualisierung...

€dit:

Die Speicherintegrität ist eine Funktion von Windows, die sicherstellt, dass Code, der im Windows-Kernel ausgeführt wird, sicher entworfen und vertrauenswürdig ist. Es verwendet die Hardware-Virtualisierung und Hyper-V, um Windows-Kernelmodus-Prozesse vor der Injektion und Ausführung von böswilligen oder nicht überprüften Codes zu schützen. Die Integrität von Code, der unter Windows ausgeführt wird, wird durch die Speicherintegrität überprüft, wodurch Windows gegen Angriffe durch bösartige Software resistent ist. Die Speicherintegrität ist eine leistungsfähige Sicherheitsgrenze, die dazu beiträgt, dass viele Arten von Malware in Windows 10-und Windows Server 2016-Umgebungen blockiert werden.

Also, wer mit Windows 10 die Speicherintegrität Sicherstellt, kann sich schon mal "sicher fühlen".

Dokumentation zur Windows-Sicherheit

Windows wurde im Kern mit Zero-Trust-Prinzipien entwickelt und bietet leistungsstarke Sicherheit von Chip bis Cloud. Da Organisationen hybride Arbeitsumgebungen nutzen, wird der Bedarf an robusten Sicherheitslösungen an oberster Stelle. Windows integriert erweiterten Hardware- und...

docs.microsoft.com

 

[fortunes]

Da liegt der Hund schon begraben...was ist mit dem zweiten SMT-Thread ?

Frag' doch AWS. Da der zweite SMT-Thread zu dem entsprechenden Core gehört, gehe ich davon aus, dass auch dieser nicht separat vergeben wird. Macht auch wenig Sinn, siehe AVX.

@fdsonne
Bislang fehlt aber ein echtes PoC, das die Lücke nachweisbar bzw. überprüfbar macht. Alles, was wir bislang haben, sind Ausführungen eines "Forscherteams", das von Intel subventioniert wird. Bei Spectre & Co. waren die PoCs auf Guthub fix verfügbar. Hier ist nix.

Also wie sollen wir prüfen, wer am Ende Recht hat?

 

[reppetstoH]

Mal ne andere Frage: Der Angriff muss, wenn ich das richtig verstehe, auf dem gleichen Kern laufen (über SMT). Wie soll das bei den Bulldozer Derivaten denn funktionieren? Da gibt es ja zwei L1Ds je Modul (also einen je Kern), aber kein SMT.

 

[fortunes]

Erstmal brauchen wir ein PoC, das die Aussagen der "Forscher" nachvollziehen lässt, Weil schreiben können die ja viel.

Welcher Code und welche Attacke wurde unter welchen Voraussetzungen verwendet?

Am Ende haben die den Angriff unter Win7 SP1 gefahren...

 

[reppetstoH]

Naja, die Reputation der Beteiligten reicht mir erstmal. Und Forscher braucht man hier nicht in Anführungszeichen setzen. Das sind Forscher. Die bisherigen Veröffentlichungen zu Zombieload und Meltdown waren ja auch korrekt. Allerdings finde ich es etwas merkwürdig, dass es in dem Bereich auch offensichtlich keinen Peer Review gibt. Normalerweise ist das ja üblich bei wissenschaftlichen Veröffentlichungen.

Auch enthält das Paper zumindest einen offensichtlichen Glitch. Dieser Satz ergibt imho keinen Sinn.

Bei einer non-inclusive Cache Hierarchie müssen Daten die aus dem L3 fallen definitiv nicht aus den L1 und L2 gestrichen werden. Das wäre eine inclusive Cache Hierarchie wo die Daten des L1 und L2 auch im L3 liegen müssen und umgekehrt. Bei einer exklusiven Hierarchie liegen auch nur Daten im L3 die aus dem L1 und L2 gestrichen wurden, da würde es noch weniger Sinn ergeben. Und bei non-inclusive machts eben auch keinen Sinn.

 

[Phantomias88]

Mal ne andere Frage: Der Angriff muss, wenn ich das richtig verstehe, auf dem gleichen Kern laufen (über SMT). Wie soll das bei den Bulldozer Derivaten denn funktionieren? Da gibt es ja zwei L1Ds je Modul (also einen je Kern), aber kein SMT.

Gute Frage, daher ja auch meine Einwand bezüglich pro Thread nicht pro Core.

Davon Abgesehen, verstehe ich es bei ZEN gar nicht, wieso es da auch funktionieren soll, weil vieles eben nicht mehr so ist wie die Architekturen davor.
z.B. https://en.wikichip.org/wiki/x86/clzero

Motivation behind:

The instruction is intended to recover from some otherwise fatal Machine Check Architecture (MCA) errors caused by uncorrectable corrupt memory. The instruction is non-cachable, unlike the PowerPC DCBZ instruction. It can not be used to allocate a cache line without a memory access, and should not be used to quickly zero memory.


Background: The Zen microarchitecture supports cache poisoning. When this feature is enabled and the memory controller detects an uncorrectable error in a data word read from ECC-capable memory, it will not cause an exception which inevitably leads to a kernel panic and system shutdown, but marks the affected bytes as "poisoned" and passes the data on to the cache controller, to be stored in the cache. Only when a CPU core attempts to read the poisoned bytes of the cache line is an exception triggered, creating an opportunity for the operating system to contain the problem and kill only the affected process. The CLZERO instruction can be used to atomically clear the whole cache line and any poisoned status.

The execution path of CLZERO is Store Queue, Store Commit, Write Combining Buffer, L2 Cache, Scalable Data Fabric, Memory.

 

[Woozy]

Und wieder eine Sicherheitslücke deren Einsatz in Freier Wildbahn nie dokumentiert wird, weil es nie eine Sau hinbekommen wird. Genau wie bei den Intel-Lücken zuvor.

 

[fortunes]

Bislang noch immer kein PoC. Keine Nachprüfbarkeit der Aussagen der Forscher.

Also wenn die Forscher diese Lücke nur mittels Spectre auf AMD-CPUs ausnutzen konnten, ist das tatsächlich keine Lücke sondern nur ein "guckt mal, man kann das auch so machen".

Und jetzt kommt eine neue Welle von Intel-Sicherheitslücken auf.

Ich werde das Gefühl nicht los, dass diese vermeintliche AMD-Lücke, die gar keine mehr ist, nur als Streufeuer gedacht war, um von den neuen Intel-Lücken abzulenken. Intel benutzt andere ja nicht zum ersten Mal, um sich besser dastehen zu lassen.

 

[fdsonne]

Ich werde das Gefühl nicht los, dass diese vermeintliche AMD-Lücke, die gar keine mehr ist, nur als Streufeuer gedacht war, um von den neuen Intel-Lücken abzulenken. Intel benutzt andere ja nicht zum ersten Mal, um sich besser dastehen zu lassen.

Eigentlich war das ja bis dato ganz sachlich hier, aber mit dem Unsinn zeigst du leider mal wieder wie unnötig solche Unterhaltungen sind. Reg dich doch stattdessen auf, dass AMD auf der Gehaltsliste der (btw. teils selben!) Entdecker für die jüngste Intel Thematik steht. Nein? Warum eigentlich nicht? Bei Intel als (Teil-)Finanzierer für das AMD Thema scheint es dich zu stören... Ist es andersrum, kommt absolut gar kein Mucks darüber.

Das PoC muss es btw. auch nicht geben. Die Lücke ist da, wurde an AMD gemeldet und die übliche Frist wurde abgewartet. Irgend ein YT Video bringt auch keinen weiter. Real praktisch ist nach Aussage des Whitepapers ein Angriff möglich. Es kann die Entropie gesenkt werden. Auch soll das auf aktuell gepatchten Systemen möglich sein. Mehr braucht es dafür nicht. Auch keine YT Videos oder PoC auf Github, die idR auf eine absolut minimalistische Laborbedingung fußen und real in der Praxis so erstmal nur bedingt bis nicht funktionieren ohne genaue Details oder entsprechende Schaffung von Bedingungen. Das ist zwar keine Sicherheit, das stimmt wohl, macht diese Art Angriffe aber eben so unnötig komplex, dass andere Angriffsvektoren viel eher in Frage kommen.

Jüngst erst wieder ein ziemlich nettes Beispiel - die NSA warnte die Tage (erneut) über eine remote ausnutzbare MS Exchange Server Lücke, welche aktiv angegriffen wird und wo mittlerweile Scans stattfinden um ungepatchte btw. ungesicherte Exchange Server zu finden. Im Resultat geht das bis hoch zu vollen AD Berechtigungen, inkl. aller Clients. (im ungünstigsten Fall)
Nochmal die Frage in den Raum, wer sowas kann, und das gibt es alle Nase lang, warum sollte dieser "wer" sich so drastisch verbiegen wollen um irgendwas über ne CPU Problematik anzustellen? Mit solchen Dingen erreicht er bestenfalls ein Ziel zu einer bestimmten Zeit und hat noch extremen Aufwand. Nen Firmen Exchange kompromittiert, Rootrechte im AD erhalten und darüber an alle Clients, Server und sonstwas im AD gekommen bringt deutlich mehr.
Hier zeigt sich halt dann auch wieder wenn unbedarfte privat User über Themen debattieren, wo sie die Brisanz und Auswirkungen gewisser Umstände gar nicht fundiert bewerten können. Aber dennoch werten und urteilen. Aber soll jeder für sich selbst entscheiden. Die CPU Lücken sind scheiße, daran gibts nix zu rütteln. Aber der Hype der darum gemacht wird, ist vielfach einfach unnötig aufgeplustert und meist extremst einseitig

 

[Holzmann]

Die Lücken ein Kommentar:

Sie werden mehr und damit größer die Lücken und schaden letztlich einer ganzen Branche, was wäre sinnvoller im Kampf gegen jene mit vereinten Kräften vor zu gehen, diese zu bündeln und
sich zu Wehr zu setzen. AMD, Intel und die anderen CPU Hersteller sollten sich an einen Tisch setzen und Strategien erörtern, was zu tun ist, jetzt und in Zukunft, um die Sicherheit von CPUs und deren Infrastruktur nachhaltig zu erhöhen. Nur so wird es möglich sein verloren gegangenes Vertrauen wieder zurück zu gewinnen, um auch am Ende sagen zu können, wir haben alles getan, was möglich war im Kampf gegen die Bedrohung.

Denn am Ende sind es eure Daten, die gefährdet sind, sowohl auf dem heimischen PC, als auch in der Cloud.

 

[fortunes]

Eigentlich war das ja bis dato ganz sachlich hier, aber mit dem Unsinn zeigst du leider mal wieder wie unnötig solche Unterhaltungen sind.

Um es abzukürzen: Du versuchst den Fakt wegzureden, dass die Forscher eine Schwachstelle gefunden haben wollen, es aber überhaupt nicht nachprüfbar machen, was und unter welchen Umständen die Schwachstelle tatsächlich ausgenutzt werden kann.

Und wie du hier lesen konntest, wirft das "White Paper" an manchen Stellen Fragen auf oder widerspricht sich sogar,

Auf all das gehst du gar nicht ein. Dir geht es nur darum, mir meinen angeblich beschränkten Horizont zu erläutern. Das ist deine Diskussionskultur. Statt die Argumente sachlich zu widerlegen gehst du auf den anderen zu und versuchst ihn dumm zu reden.

Gelingt dir nur leider nicht, weil deine Masche nicht zieht.

Die Problematik ist jetzt ca. 6 Monate bekannt. Und bis heute gibt es kein PoC, dass die Forscher mit dem, was sie als "neu" deklarieren, Recht haben. Mag sein, dass es diese Lücke gibt. Aber bislang steht der Verdacht, dass diese Lücke nicht neu ist, sondern schon "gefixt" wurde oder mindestens eine offene, als gesichert geltende Schwachstelle voraussetzt.

Deine Diskussionskultur, wenn dir die Argumente ausgehen, ist einfach nur noch lächerlich. Und das als Moderator.