News Meltdown & Spectre: Details und Bench­marks zu den Sicherheits­lücken in CPUs

[Miuwa]

Was genau sollen die Microcode updates jetzt eigentlich fixen?

 

[Jesterfox]

So wie ich das gelesen haben fixen die Microcode Updates ein Problem der CPUs ab Haswell das verhindert dass der OS-Patch Wirkung zeigt (einfach weil eine Optimierung die CPU evtl. trotzdem auf das alte verhalten zurückfallen lässt). Für Ivy/Sandy Bridge ist das wohl nicht notwendig.

 

[I'm unknown]

@unknown: verwechselt, jeder hier weiss was gemeint ist!!

Eben nicht, schau dir doch mal nur das letzte falsche Posting bezüglich Microcode-Updates von Jesterfox an...

Der Rest ist Futur III

Hatte ich damals auch gelesen - eine geniale Idee .

 

[Jesterfox]

Hast du da nen Link dazu der was anderes erzählt? Die Berichte die ich bisher kenne beschreiben das genau so...

 

[I'm unknown]

Intel hat noch nicht verkündet was mit älteren CPUs passieren wird. Das bedeutet jedoch nicht, dass die Updates nicht erforderlich wären...

 

[Jesterfox]

Ich bezieh mich halt hierauf:

Using retpoline for sensitive branches doesn't work reliably on the latest (Broadwell or better) Intel processors, because those processors can, in fact, use the branch predictor instead of the return buffers. When returning from deep function nesting (function A calls function B calls function C calls function D...), the return buffers can be emptied. Broadwell-or-better don't give up in this scenario; they fall back on the BTB. This means that on Broadwell or better, even retpoline code can end up using the attacker-prepared BTB. Intel says that a microcode update will address this. Alternatively, there are ways to "refill" the return buffer.

https://arstechnica.com/gadgets/201...e-and-meltdown-patches-will-hurt-performance/

 

[I'm unknown]

Für IvyBridge-EP gibt es aktuelle Microcodes...

 

[Jesterfox]

Ok, die Info war mir bisher noch nicht über den Weg gelaufen... aber irgendwie gibt's leider auch keine Stelle die mal sauber alle Fakten zusammenträgt. Wenn sich die verschiedenen Stellen dann noch widersprechen weil sie auf unterschiedlichem Stand was die Fakten angeht sind ist die Verwirrung halt komplett.

 

[Iscaran]

@Jesterfox:
Im Prinzip kann man es relativ simpel zusammenfassen:

https://www.kb.cert.org/vuls/id/584653



Spectre1: Patch im OS / bzw. jeder Software einzeln nötig
Spectre2: Patch im OS aber zusätzlich Microcodeupdate erforderlich das durch den Patch im OS erst "scharf" geschaltet wird.
Fehlt eins von beiden ist kein Schutz da.
Meltdown: KPTI-Patch auf OS-Ebene (nur relevant auf Intel und manchen ARM systemen)
AFAIK (betrifft die ARM-Systeme auch nur die "schwächere" Meltdown variante 3a bis auf eine einzige CPU die auch von V3 (Meltdown) wie Intel betroffen ist).

Spectre 1: Betrifft JEDE Cpu die Speculative Executions ausführt wenn ein Angriff auf die Ausführende Software direkt ausgeführt werden kann (also z.B. ein Angriff auf Firefox direkt via problematischen Code der in FF zur Ausführung kommt.)
Spectre 2: Betrifft theoretisch jede CPU die Speculative Executions ausführt. Praktisch ist aber vor allem Intel betroffen da Intels Branch Predictor (Vorhersagealgorithmus) mit unvollständigen Adressbereichslokalisierungen arbeitet und deswegen die Injektion eines Offsets auf alternative Speicheradresse erlaubt (bzw. stark erleichtert)
Bei AMD geht man davon aus dass ein effektive Ausnutzen der Lücke wegen der immer vollständigen Adressbereichslokalisierung im Branch Predictor ein effektives ausnutzen der Lücke zu nicht autorisierten Adressbereich deutlich erschwert wenn nicht sogar faktisch unmöglich macht (man müsste schon quasi die zu attackierende Software stark fehlerhaft schreiben/präparieren)
Meltdown: Betrifft Jede Intel CPU seit Nehalem. Betrifft einige ARM CPUs. Betrifft AMD CPUs wohl nicht. Details zum warum sind mir aber nicht bekannt.

 

[engine]

Vorsicht, Meltdown / Spectre Gefälschte BSI Emails mit Malware im Umlauf

http://www.pcgameshardware.de/Siche...te-BSI-Emails-mit-Malware-im-Umflauf-1247801/

Hätte ich nicht mal geöffnet. Aber so eine Mail habe ich nicht, daher gehe ich davon aus, dass meine Mail-Adressen nicht so sehr im Umlauf sind .

Leichte Formulierungsschwäche:

... Derzeit geht eine Spam-E-Mail-Welle um sich ...

 

[yummycandy]

@ Iscaran,

Meltdown: Intel CPUs und wohl einige ARMs sind betroffen, weil sie Kernelspeicher und den gesamten physischen Adressraum in die Seitentabelle jedes Userprozesses mappen. Durch Ausnutzen der Trägheit der, bei Zugriffsverletzung geworfenen, Exceptions, kann man gezielt Speicheradressen in den eigentlich geschützten Bereichen auslesen.

Durch das Mappen besteht ein Performancevorteil, weil kein Kontextswitch zwischen User- und Kernelspeicherbereich nötig wird.

 

[Sepp Depp]

List Of CPUs Vulnerable To Meltdown / Spectre

https://www.techarp.com/guides/complete-meltdown-spectre-cpu-list/

 

[kisser]

@ Iscaran,

Meltdown: Intel CPUs und wohl einige ARMs sind betroffen, weil sie Kernelspeicher und den gesamten physischen Adressraum in die Seitentabelle jedes Userprozesses mappen.

Das machen alle Betriebssysteme (zumindest bis vor Meltdown ) , das ist keine Eigenschaft der CPUs.
Deshalb macht man ja jetzt KPTI gegen Meltdown auf Betriebssystemebene.

 

[Iscaran]

@yummycandy

Danke für diese Erläuterung...d.H. aber das AMD vermutlich immun ist da sie dieses Mapping nicht betreiben (?). Denn der Kontexswitch zw. User und Kernel space ist ja eine wichtige Sicherheitsbarriere - wenn man den aus Performancegründen bei Intel aufgegeben hat, tja....selbst Schuld.

Danke @sepp:

Der TechArp Artikel ist endlich mal eine sehr gute zusammenfassung !!!

Btw @ Stunrise:

How Bad Is This CPU Bug?

• The Spectre attack lets the attacker access and copy information from the memory space used by other applications.
• The Meltdown attack lets the attacker copy the entire physical memory of the computer.
• Unless patched, the affected processors are vulnerable to malware and cyberattacks that exploits this CPU bug to steal critical information from running apps (like login and credit card information, emails, photos, documents, etc.)
• While the Meltdown exploit can be “fixed”, it is likely that the Spectre exploit cannot be fixed, only mitigated, without a redesign of the processors. That could mean we may have to live with the risks of a Spectre attack for many more years to come.

Muss jeder selber wissen wie "kritisch" ihm Meltdown ist.

 

[yummycandy]

Das machen alle Betriebssysteme (zumindest bis vor Meltdown ) , das ist keine Eigenschaft der CPUs.
Dehslan macht man ja jetzt KPTI gegen Meltdown auf Betriebssystemebene.

War ein bissl uneindeutig. Hier nochmal besser:

Meltdown: Betriebssysteme mappen Kernelspeicher und den gesamten physischen Adressraum in die Seitentabelle jedes Userprozesses.

Normalerweise werden Exceptions geworfen, sobald klar wird, daß eine Zugriffsverletzung stattfindet. Bei Intel und einigen ARM-CPUs erfolgen diese Exceptions erst nach einiger Trägheit und so ist es möglich, daß bestimmte Anweisungen schon auf geschützte Bereiche zugreifen konnten.

 

[engine]

...
Der TechArp Artikel ist endlich mal eine sehr gute zusammenfassung !!!
...

Obwohl hier im Artikel schon viel steht, mehrere Meinungen sind immer gut.
Ich finde die besser, wobei man immer bedenken muss, eine Malware, die diese Lücken ausnutzt ist gefährlich, nicht die Lücken selber:

07.01.2018
Frank Riemenschneider

Fazit

Spectre Variante 2 erscheint auf der einen Seite das für den Hacker herausfordernste Szenario zu sein, da es erhebliches Know-How über die Sprungvorhersage-Implementierung auf einer spezifischen CPU erfordert. Auf der anderen Seite erfordert es auch den höchsten Aufwand, um sich dagegen zu wehren, da ohne vollständige Code-Recompilierung und grundsätzlich Ersatz der indirekten Sprungvorhersage durch eine andere Codesequenz derzeit kein Schutz möglich erscheint. Die Abschaltung von Hyperthreading scheint derzeit unausweichlich zu sein, was zu erheblichen Performance-Einbußen führen dürfte. Die gute Nachricht ist, dass ein Remote-Angriff nicht möglich ist.

Auch bei Spectre Variante 1 wird man wie oben gezeigt ohne Code-Recompilierung nicht weiterkommen, da eine vollständige Abschaltung von spekulativen Speicherzugriffen nicht praktikabel ist. Von den Compilern muss erwartet werden, potentiell gefährliche Code-Sequenzen zu erkennen und die wirksamen Instruktionen zur Code-Serialisierung (siehe oben) einzufügen. Ein Remote-Angriff könnte theoretisch zwar möglich ein, aber in Praxis eher nicht, schon wegen der Frage, wie er von den relevanten Cache-Lines ein Timing-Signal zurückerhalten soll.

Meltdown wird nach Implementierung der gezeigten Kernel-Page-Table-Isolation Geschichte sein. Derzeit arbeiten nicht nur alle bekannten OS-Hersteller, sondern auch Browser-Herseller an Fixes, denn auch Implementierungen in Java-Script waren laut den Forschern erfolgreich. Von den Auswirkungen ist Meltdown schon deshalb von allen Angriffsszenarien sicher am Katastrophalsten.

Spannend werden die Auswirkungen der Fixes auf die Rechenleistung sein. Besonders Programme, die einen häufigen Kontextwechsel aufweisen, werden nach den Updates leiden. Die Sekretärin/der Sekretär mit MS-Word dürfte hingegen vergleichsweise wenig merken.

http://www.elektroniknet.de/design-...n-und-die-gegenmassnahmen-149200-Seite-5.html

 

[Iscaran]

@engine:

JA die von eletroniknet.de ist auch wirklich sehr gut ! Aber ich bin mir nicht 100% sicher ob Hr. Riemenschneider das ganze Problem nicht vor allem (oder nur ?) aus ARM-Sicht beleuchtet (also die Bedruohungslage) ?

 

[engine]

Zu Spectre 2, wenn der Performanceeinbruch bei älteren CPUs wirklich so gravierend ist, wünsche ich mir gar kein Microcode-Update, sondern bin lieber noch etwas vorsichtiger, denn bis eine neue CPU-Architektur erscheint oder eine ganz sicher empfohlen wird, dauert es wohl noch eine Weile.
Ich bin auch kein Malwaresammler sondern meide sie lieber .

 

[kisser]

War ein bissl uneindeutig. Hier nochmal besser:

Meltdown: Betriebssysteme mappen Kernelspeicher und den gesamten physischen Adressraum in die Seitentabelle jedes Userprozesses.

Immer noch missverständlich
Die Page Tables (Seitentabelle) mappt virtuelle auf physikalische Adressen.
Die Page table existiert einmal für jeden (User)Prozess.
Im virtuellen Adressraum des Prozesses sind auch die kompletten virtuellen Adressen des OS-Kernels abgelegt (und damit das gesamte Mapping auf die physikalischen Adressen des Kernels und des (User)Prozesses)

https://en.wikipedia.org/wiki/Page_table

Mit ASLR hat man versucht, Angriffe durch Buffer-Overflows zu erschweren, indem man die zum Kernel gehörenden virtuellen Adressen für jeden User-Prozess ändert.

https://de.wikipedia.org/wiki/Address_Space_Layout_Randomization

Das nützt bei Meltdown nichts mehr, weil der gesamte (virtuelle) Adressraum quasi vom Angreifer durchsucht werden kann.

 

[yummycandy]

Das nützt bei Meltdown nichts mehr, weil der gesamte (virtuelle) Adressraum quasi vom Angreifer durchsucht werden kann.

Dagegen soll eigentlich das Supervisor Bit helfen. Das greift widerum unter den genannten Umständen nicht und Instruktionen können trotzdem ausgeführt werden.