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

wickedgonewild schrieb:
Ich hab Montag den ersten Arbeitstag, und wir betreuen rund 6000 Rechner mit unterschiedlichster Hardware und Software.
Das neue Jahr fängt echt gut an.
Ich wünsche Dir schonmal viel Spaß! ;)
 
Also bei mir geht der Patch nicht.. kriege Fehlermeldung:

• 2018-01 Kumulatives Update für Windows 10 Version 1709 für x64-basierte Systeme (KB4056892) – Fehler 0x800f081f
 
xexex schrieb:
Mit dem Angriff ist es aber nicht möglich den gesamten Speicher in Echtzeit zu überwachen. Ich habe nie behauptet die ganze Geschichte wäre Blödsinn, es wird aber auch bewusst vom Worstcase ausgegangen. Um dein Kennwort abzugreifen müsste eine Malware bereits im Hintergrund laufen und mit etwas Glück die Adresse der Applikation kennen in die du dein Kennwort eingibst.

Google hat ja am Beispiel gezeigt, wie sie Kennwörter im Klartext von einem Apache Server auslesen können. Es ist aber auch ein Sicherheitsrisiko, dass anscheinend der Apache Server die Kennwörter unverschlüsselt im Speicher hält. Dass es bei weitem nicht auf jede Applikation zutrifft habe ich bereits anhand von DPAPI unter Windows aufgeführt.
[...]

Im "Normalfall" haben jedoch Klartextkennwörter im RAM, aus verschiedenen Gründen nichts verloren, das ist nicht erst seit Meltdown so.

Der Wikipedia-Artikel widerspricht sich selbst und dir aber mittlerweile...

Suppose the attacker is in control of an unprivileged user-space process, which is normally prevented from reading at a protected memory address Ap by the CPU's memory protection mechanism. To circumvent such memory protection and read bit 0 at Ap, the attacker executes the following sequence of instructions:

1. Clears the cache for (attacker's address space, accessible) addresses A0u and A1u
2. Reads the value V(Ap) of a protected memory location at address Ap to a register
3. Crafts, as Axu, via a bitwise arithmetic operation, address A0u or A1u, depending on the value of bit 0 of V(Ap)
4. Reads the memory at address Axu

The CPU's memory protection mechanism will raise a memory protection fault when reading from the protected address Ap at step 2. However, since waiting for the memory protection hardware to finish its checks can cause significant slowdowns, affected CPUs will actually execute steps 2--4 speculatively, and only annul their effects when the memory protection fault gets detected some clock cycles later. Only the so-called "architectural" effects are annulled; the speculative execution of step 4 causes the memory at Axu to be loaded into the cache, and this is not undone. The attacker then reads, via a previously forked process or a memory transaction, (Anmerkung sun_set_1: richtig, hier braucht man Zusatzsoftware. Dazu später mehr) "his" A0u and A1u, timing both accesses. This timing will determine which of the two locations is now in cache, and thus reveal the value of memory bit 0 at address Ap. (Hier kennst Du mit b0 auf Ap d

Repeating the above for other bits of V(Ap) will reveal those other bits as well.
(Counter und Schleife in den Befehl, das wars. Du kannst jeden Bereich den du möchtest automatisiert auslesen)

The above depends on the implementation of the address translation mechanism in the OS and the underlying hardware architecture. The attack can reveal the content of any memory which is mapped into a user address space, even if otherwise protected.

Bei dem Wikipedia Beispiel geht es um das praktische Auslesen eines Speicherbereiches.
Ein Teil des Meltdown Bugs ist aber, dass auch Memory Mapping’s geleaked werden können. Das geht implizit auch aus dem Wikipedia Artikel hervor. Du kannst Bit 0 von Ap bestimmen, sprich den Anfang des geschützten Speichers.

Nach Schritt 2 ist dieser erstmal auf hold und die memory protection läuft durch. Sie braucht aber 2bis 3 Taktungen währenddessen Du als Angreifer prinzipiell tun und lassen kannst was Du möchtest, da Intel x86 nun ohne Überprüfung im Rahmen der speculative execution Schritt 3 und 4 ausführt. Anstelle von Speicherinhalten, liest man also einfach zunächst die Memory Mappings aus. Bye Bye ASLR.

Die Daten in Ap sind nicht verschlüsselt, da dies ja der Bereich ist der eigentlich verschlüsselt ist. Sobald die CPU hieraus aber Daten ausliest, muss das natürlich im Klartext geschehen. Wie sollten verschlüsselte Daten sonst jemals verarbeitet werden?

Det is ja dat Dilemma.

Hier auch nochmal von arstechnica

The first wind of this problem came from researchers from Graz Technical University in Austria. The information leakage they discovered was enough to undermine kernel mode Address Space Layout Randomization (kernel ASLR, or KASLR).

https://arstechnica.com/gadgets/2018/01/whats-behind-the-intel-design-flaw-forcing-numerous-patches/

Wie in allen Artikeln geschrieben, war aber das der Uni Graz erstmal der kickoff des ganzen Problemes.

Was den Einwand von Dir mit der Zusatzsoftware angeht.

Bekanntermaßen muss man Code auf dem System ausführen können um die Lücke zu nutzen. Sobald ich aber ein Drive-by, worüber auch immer, generiere (Website, Applikation, USB-Stick) ist doch das alle n überhaupt kein Problem. Die Fähigkeit Code auszuführen und zB potenzielle Programme zu identifizieren, ist doch Grundvoraussetzung für das Nutzen der Lücke. Daher erschließt sich mir das Argument nicht ganz.

Man kann auch sagen, „man muss erstmal aufs System kommen“.
- Ja, ok. Das war soweit bekannt? Bzw ist bei letztlich jedem Hack so.
Es geht doch darum, dass dann alle weiteren Mechanismen wie eben ASLR die UAC, Richtlinien, bla bla nicht mehr greifen.
 
Zuletzt bearbeitet:
Das größte Problem sind mMn gar nicht die gewöhnlichen Computer. Sicherlich: Es gibt etliche wichtige Systeme, die sogar noch auf XP laufen und vmtl. nie einen Patch sehen werden - Fahrkartenautomaten, Geldautomaten, Anzeigetafeln etc. Aber alle diese Systeme haben ein Unternehmen hinter sich, in dem ITler arbeiten, die das Risiko einschätzen können und dort, wo es möglich und nötig ist auch eingreifen können. Klappt zwar nicht immer so wie es soll, aber zumindest besteht die Möglichkeit da einzugreifen.

Und wenn es um PCs geht: Da werden die meisten Anwender ja mit Updates versorgt.

Aber wenn es um Smartphones geht: Da wird es für die allermeisten Geräte keinerlei Sicherheitsupdates geben - die Lücken bleiben. Und der gewöhnlich Bürger ist eben leider kein IT-Experte, der selbst was dagegen unternehmen könnte. Neues Gerät, das (noch) mit Updates versorgt wird zu kaufen kostet ein paar hunnis, werden also auch die wenigsten machen.

Ergo: Wenn keine Wunder geschieht, wird es noch über Jahre hinweg millionen von Smartphones geben, die keinen einzigen Patch bekommen haben. Geht mir selbst ähnlich: Hab ein erst 2 Jahre altes Smartphone mit Android 5.1, gibt keine Updates dafür. 200-300€ für ein neues, das (noch) mit Updates versorgt wird? Nein Danke. Wenn ich also nicht selbst etwas unternehme, werde ich noch einige Jahre ein Smartphone verwenden, das anfällig für Spectre (und vmtl. noch so ein paar hundert andere Expolits) ist.
 
Artikel-Update: Google schafft Klarheit

In einem neuen Blog-Eintrag hat Google eigene Erfahrungen mit den Leistungseinbußen sowie Klarstellungen zu den drei Problemvarianten veröffentlicht. Man habe sowohl Page-Table Isolation (PTI) als auch eine Spectre-Gegenmaßnahme namens Retpoline, die seit heute auch von den Linux-Entwicklern diskutiert wird, auf allen Google-Servern (unter anderem Search, Gmail, YouTube und Cloud Platform) eingespielt und anschließend nur vernachlässigbare („negligible“) Leistungseinbußen festgestellt. Jene könnten natürlich von Fall zu Fall abweichen, die Ergebnisse mancher Microbenchmarks seien aber mitnichten auf reale Anwendungen übertragbar.

Darüber hinaus hat Google Klarstellungen zu den drei Problemvarianten veröffentlicht. Einfach ist der Fall bei Meltdown („Variant 3“): Gegen diese einfach ausnutzbare aber auch relativ einfach behebbare Sicherheitslücke, die ausschließlich Intel-CPUs und wenige ARM-Kerne betrifft, helfen die PTI-Patches für Linux beziehungsweise das heute veröffentlichte Windows-Update.

Bei Spectre („Variant 1“ und „Variant 2“), wovon auch CPUs von AMD und ARM betroffen sind, ist die Sache komplizierter. „Variant 1 (bounds check bypass)“ könne nur entgegengewirkt werden, indem jede betroffene Anwendung einzeln angepasst wird. Deshalb werden beispielsweise Google Chrome und Firefox die weiter oben beschriebenen Updates erhalten. „Variant 2 (branch target injection)“, von der AMD behauptet prakisch nicht betroffen zu sein („near-zero risk“), könne durch Microcode-Updates des CPU-Herstellers oder durch die neue „Retpoline“-Technik entschärft werden. Jene könne dazu in betroffene Betriebssysteme, Hypervisors, Systemprogramme, Bibliotheken und Anwendungen eingebaut werden.

Stellungnahme von ARM
Welche der in praktisch allen Smartphones verbauten ARM-SoCs von welchen der drei Probleme betroffen sind, steht übrigens sehr übersichtlich auf der ARM-Website: Arm Processor Security Update. Demnach sind zumindest prinzipiell – laut Google gibt es für Android ja noch keinen funktionierenden Exploit – 4 ARM-Kerne von Meltdown und 10 ARM-Kerne von Spectre betroffen.

Diese Transparenz ändert leider nichts daran, dass viele Android-Nutzer aufgrund der nach wie vor schlechten Update-Versorgung solche Sicherheits-Updates vermutlich niemals erhalten werden. Viele Android-Nutzer werden sich also vermutlich an den Strohhalm klammern müssen, dass es laut Google unter Android bislang nicht gelungen sei, die Sicherheitslücken auszunutzen (siehe das Update vom 3.1.2018 23:51 Uhr).
 
iNFECTED_pHILZ schrieb:
Das einzige was ich mir vorstellen könnte wo man Intel ( falls es wirklich so war und bewiesen werden kann) an den Eiern hat, ist der vorgezogene Start von CL bzw SL-X. Falls die noch schnell ihre Lager leer machen wollten bevor das hier herauskommt, kann das unter Umständen richtig ärger geben.
Die anhaltend schlechte Verfügbarkeit von CL wäre zumindest ein Indiz, dass hier nur abverkauft aber kaum nachproduziert wird. Wie das zu deuten ist, haben andere Leute zu entscheiden.
Wir bleiben gespannt

Hab vorhin im ARD gesehen, dass ein Intel-Chef fast all seine Intel-Aktien kurz vor Weihnachten verkauft hat. Im Wert von 25 Millionen Euro!
Die wussten locker schon viel länger Bescheid über diese Lücken!
 
Dr. MaRV schrieb:
Deshalb interessiert mich ja, ob es wirklich jede ARM (basierte) CPU betrifft oder nicht. ARM ist nämlich in jedem (mobilen) Gerät vorhanden.
Das geht über Smarthome Hardware, weiter zu Routern, Switchen, Smartphones, selbst im MacBook und iMac Pro sind ARM CPUs verbaut. Darum auch die Fragestellung Apples A-SOCs, also A9, A10, A11 etc...
Das einzig gute ist, das der Spectre Bug wohl schwer auszunutzen sein soll.

Danke für die Info Dr.MaRV ich bin echt mal gespand was am ende raus kommt
 
Beitrag schrieb:
Ergo: Wenn keine Wunder geschieht, wird es noch über Jahre hinweg millionen von Smartphones geben, die keinen einzigen Patch bekommen haben
Das betrifft ja dann möglicherweise nicht nur die "alten" Smartphones sondern auch die "aktuellen", die sich im Abverkauf befinden. Eigentlich betrifft es möglicherweise jede Form von Hardware...

Ich glaube, ich werde dann erst einmal nichts neues mehr kaufen, bis man davon ausgehen kann, dass alle im Handel befindlichen Geräte keine anfälligen Chips mehr enthalten...

So eine Hardwareabstinenz schont den Geldbeutel und wohl auch die Nerven;)

Gruß,
CTN
 
Dr. MaRV schrieb:
Deshalb interessiert mich ja, ob es wirklich jede ARM (basierte) CPU betrifft oder nicht. ARM ist nämlich in jedem (mobilen) Gerät vorhanden.

Sind nicht alle betroffen, es sind nur bestimmte Prozessoren der A- und R-Serie betroffen.
Für "Spectre" (Variant 1 und 2) , also die harmlosere Variante, sind alle A und R-Prozessoren betroffen.

Für "melddown" (Variant 3) sind es einige der A-Serie. ARM hat es vorbildlich aufgelistet und bietet volle Transparenz, was nicht für die Blauen gilt ...

https://developer.arm.com/support/security-update
 
Ich kann gar nicht beschreiben wie wenig mich eventuelle Sammelklagen, nicht funktionierende Tuning-Tools oder Performanceminderungen im Promille- bis einstelligen Prozentbereich interessieren.

Mich als Otto-Normal Nutzer interessiert nur ob ich neben der Installation des Patches, einen Browser mit NoScript, uMatrix & Co und eben keinen Passwortmanager zu verwernden noch etwas tun kann? Denn weder den PC gar nicht nutzen noch JavaScript beim browsen komplett bzw überall zu deaktivieren sind realistische Optionen im Alltag.
 
TheLastHotfix schrieb:
den Patch konnt ich zwar einspielen, er wirkt nur nicht unter Windows 10.

Also bei mir scheint der Patch zu wirken Win 10 x64 Pro:

BTIHardwarePresent : False
BTIWindowsSupportPresent : True
BTIWindowsSupportEnabled : False
BTIDisabledBySystemPolicy : False
BTIDisabledByNoHardwareSupport : True
KVAShadowRequired : True
KVAShadowWindowsSupportPresent : True
KVAShadowWindowsSupportEnabled : True
KVAShadowPcidEnabled : True
 
TGoP schrieb:
Mich als Otto-Normal Nutzer interessiert nur ob ich neben der Installation des Patches, einen Browser mit NoScript, uMatrix & Co und eben keinen Passwortmanager zu verwernden noch etwas tun kann? Denn weder den PC gar nicht nutzen noch JavaScript beim browsen komplett bzw überall zu deaktivieren sind realistische Optionen im Alltag.

Das perfide an den Lücken ist, daß du gar nichts weiter machen kannst, außer Patches zu installieren und zu hoffen, daß deine benutzten Programme auch ein Update erhalten. Du kannst nicht einmal nachprüfen, ob du bereits erwischt wurdest.
 
Zurück
Oben