News CacheWarp: Neue Sicherheitslücke mit Heilmittel in CPUs von AMD

[0x8100]

Warum verwendet die Software für "authentifiziert" einen Wert, mit dem Variablen üblicherweise initialisiert werden.

0 bedeutet "ok", alles andere ist ein fehler und der wert zeigt dann den grund an. dieses vorgehen wird z.b. bei return-codes von programmen benutzt und ist beim programmieren üblich.

 

[foofoobar]

Man könnte aber auch andersrum argumentieren. Warum verwendet die Software für "authentifiziert" einen Wert, mit dem Variablen üblicherweise initialisiert werden. Null oder 0 (bzw \0 bei Zeichenketten) sind doch gängiger Standard als Initialisierung Werte.

Denk einfach an Funktionen die einen Pointer zurück liefern.

 

[Caramon2]

Das ist bescheuert.

Irgendwie hat das was von einem Tresor mit Zahlenschloss, das standardmäßig offen ist und erst verriegelt, wenn man den falschen Code eingibt.

 

[davidzo]

Das ist sowieso kompletter Kokolores und totaler Humbug.
Woher willst du gesichert wissen welche Eigenschaften deine VM hat?

Easy, das ist ja sogar meistens der Fall weil fast jeder fertige Disk images nutzt anstatt from scratch zu installieren. Wenn ich bei Digital Ocean eine standard MySQL Droplet starte, dann sieht erstmal jede VM damit gleich aus. Mit welchen anderen Kunden ich auf einem Host liege ist eher die Schwierigkeit, aber das kann man bestimmt auch herausfinden.

 

[spamarama]

Das ist sowieso kompletter Kokolores und totaler Humbug.
Woher willst du gesichert wissen welche Eigenschaften deine VM hat?

Ergänzung (14. November 2023)

In der Tat ist das Angreifermodell Humbug. Wenn man dem Host nicht traut, sollte man dort keine VM laufen lassen.

 

[gustlegga]

Gehts wieder darum den PC durch "Sicherheitsupdates" langsamer zu machen, so das wieder neue CPUs gekauft werden ?

Klar, Intel bezahlt die Uni Graz und das Helmholtz Institut um abstrakte Lücken in AMD CPUs zu finden, damit die Leute instantan in den Laden rennen und Xeons kaufen.

 

[foofoobar]

Gehts wieder darum den PC durch "Sicherheitsupdates" langsamer zu machen, so das wieder neue CPUs gekauft werden ?

Wer lesen kann ich auch hier klar im Vorteil.

 

[Crassus88]

Klar, aber erst muss dafür jemand auf dein Notebook kommen, das ist dann wahrscheinlich eh das größere Problem.

Das ist wohl war, da haberts noch an einer anderen, Schwächeren Stelle.

 

[Knuddelbearli]

Siehste Intel so geht das, und nicht die Lücke einfach 4 Jahre geheim halten und dann in Panik verfallen!

 

[BrollyLSSJ]

Danke für die News. Mal gucken, was davon bei uns zum Einsatz kommt.

 

[Bigfoot29]

Danke für die Klarstellung(en)!
Ich bin mir gefühlt ziemlich sicher, dass die letzte Zeile da noch nicht stand. Sowas überlese ich eigentlich selten, wenn es direkt dahinter steht. (Andererseits: Auch ich werde älter. )

Kurzer Einwurf zur Frage, warum der Exploit ein Problem sei: Es gibt bei VMs im Prinzip 3 Bedrohungsszenarien:

• Jemand bricht von außen in DEINE VM ein.
• Jemand vom Admin-Team tut böse Dinge, um in Deiner VM Blödsinn zu treiben
• Jemand bricht aus einer ANDEREN VM aus und in Deine VM ein.

Bei ersterem hilft nur klassisches Patchen und Hardening. Mach Deinen Kram sicher, dann gibts auch keine größeren Angriffsvektoren, die einfach(!) angreifbar sind bzw. die Du als Admin zu verantworten hast.

Beim zweiten Punkt musst Du leider Deinem Betreiber vertrauen, dass der eine korrekte Policy hat, wenn es um Einstellungen/Überwachung und Co geht. Denn egal, was die Schlangenöl-Verkäufer sagen: Der Hypervisor-Anbieter kann IMMER irgendwie mitlesen. Notfalls mit etwas Aufwand.

Punkt Nr.3 sehe ich als Haupteinsatzgebiet der aktuellen RAM-Verschlüsselung und -Absicherung. Wenn jemand aus einer anderen VM "herausplatzt", hat er erstmal undefinierte Rechte von Root-Zugriff bis hin zu "Nobody". Hier können die Sicherheitsmechanismen den Angreifer lange genug aussperren, bis sich sein Angriff nicht mehr lohnt und/oder die Kompromittierung durch die übernommene VM durch das Hypervisor-Team erkannt wird. Im besten Fall sieht der "Ausbrecher" dann nur noch den Speicher seiner eigenen VM und kann nichts anderes mehr lesen/verändern.

Aber letztlich gilt leider wie immer: Sobald ein Rechner in irgend einer Art Zugriff durch Dritte erlaubt (physisch, remote), hat er als kompromittiert / kompromittierbar zu gelten. Denn ab diesem Zeitpunkt ist es nur eine Frage der Zeit und des Interesses der Dritten an den Ressourcen oder Inhalten, bis jemand deine Umgebung knackt.

Regards, Bigfoot29

 

[Miuwa]

In der Tat ist das Angreifermodell Humbug. Wenn man dem Host nicht traut, sollte man dort keine VM laufen lassen.

Würde ich nicht so schwarz/weiß sehen. Vertrauen ist ja auch keine Binäre Sache.

 

[spamarama]

Alles eine Risikoabwägung. Hängt immer davon ab, gegen was man sich absichern will. Wenn ich die NSA wäre, würde ich mein Zeug auch bei AWS hosten. Als FSB vielleicht besser nicht.

 

[Miuwa]

Kurzer Einwurf zur Frage, warum der Exploit ein Problem sei: Es gibt bei VMs im Prinzip 3 Bedrohungsszenarien:

• Jemand bricht von außen in DEINE VM ein.
• Jemand vom Admin-Team tut böse Dinge, um in Deiner VM Blödsinn zu treiben
• Jemand bricht aus einer ANDEREN VM aus und in Deine VM ein.

[...]

Beim zweiten Punkt musst Du leider Deinem Betreiber vertrauen, dass der eine korrekte Policy hat, wenn es um Einstellungen/Überwachung und Co geht. Denn egal, was die Schlangenöl-Verkäufer sagen: Der Hypervisor-Anbieter kann IMMER irgendwie mitlesen. Notfalls mit etwas Aufwand.

Auch das würde ich nicht so schwarz/weiß sehen. Es macht ja z.B. nen riesen Unterschied, ob der Anbieter "aus versehen" mitlesen kann oder ob es kriminelle Energie braucht. Ich weiß nicht, wie relevant das bei VMs ist, aber der Klassiker bei Programmen, die sensible Daten verarbeitet sind ja crashdumps, die diese Enthalten und dann ungereinigt weitergegeben werden. Evtl. gibt's dazu auch bei VMs ein Äquivalent.

 

[Nagilum99]

Mal schauen wann das Update für mein alten 7401P kommt.

Du solltest den Artikel nochmal genau lesen, speziell der Absatz:

Neuer Microcode nur für Milan​

in genau diese virtuellen Arbeitsumgebungen einzudringen, obwohl AMDs Secure Encrypted Virtualization (SEV) genau das eigentlich verhindern soll. Aber genau dort liegt das Problem.

Da nimmt es jemand sehr genau.

Ergänzung (16. November 2023)

"Forschenden" ? ! Euer ernst ?? Man muss nicht jeden Scheiß mitmachen. Die Deutsche Sprache zu vergewaltigen ist bestimmt nicht Euer Auftrag !!!

Ich empfehle: Binnen-I be gone
Das arbeitet fast fehlerfrei und man sieht den Blödsinn gar nicht erst.

Ergänzung (16. November 2023)

Im Übrigen find ich's widerlich, wie damit echte Sexualdelikte verharmlost werden.

🐟

 

[Merkmal]

@Jan
Es gibt eine neue Schwachstelle in UEFI.

UEFI-Schwachstelle LogoFAIL: Secure Boot mit manipulierten Bootlogos umgehbar - heise.de

Intel Nucs sollen teilweise einen fix erhalten haben.

PRODUCTS: NUC10i7FN, NUC10i5FN, NUC10i3FN
Fixed issue where LogoFAIL vulnerability.

Quelle: downloadmirror.intel.com/793744/FN_0063_ReleaseNotes.pdf

Siehe Intel.de BIOS-Update [FNCML357] Release Notes (FN_0063_ReleaseNotes.pdf)