Spectre und Meltdown

Hier habe ich mal ein Batch Script geschrieben, das euch die CPUID bzw. Signature der CPU und die Microcode Version des BIOS und, sofern manuell geladen, der manuell geladenen Version unter Windows anzeigt:

echo off
echo "CPUID/SIGNATURE (Model ist in Dezimalschreibweise):"
reg query HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0\ /v "Identifier"
echo "Im Bios enthaltende Microcode Version:"
reg query HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0\ /v "Previous Update Signature"
echo "Versionsnummer einer manuell geladenen Microcode Version: (falls leer = Fehlermeldung)"
reg query HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0\ /v "Update Revision"

Das ganze einfach in einem Editor wie Notepad einfügen und mit der Dateinamenserweiterung ".bat" abspeichern.
Danach einfach in der Powershell oder Eingabeaufforderung starten.
Ich empfehle die Powershell, da man hier längere Zeilen ohne Zeilenumbruch darstellen kann.

Wer das Skript optimieren möchte, kann das gerne tun.

Mein Batch Script hat leider den Falschen Schlüssel ausgewertet, hier ist eine korrigierte Version.
Diese kann man auch per Mausklick starten, das Fenster bleibt danach noch geöffnet:

echo off
echo "CPUID/SIGNATURE (Model ist in Dezimalschreibweise):"
reg query HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0\ /v "Identifier"
echo "Im Bios enthaltende Microcode Version:"
reg query HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0\ /v "Previous Update Signature"
echo "Versionsnummer einer manuell geladenen Microcode Version: (falls leer = Fehlermeldung)"
reg query HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0\ /v "Update Signature"
PAUSE

Das Microcode Update habe ich übrigens auch ausgeführt, allerdings scheint der Microcode nicht geladen zu werden.
Ich habe immer noch die gleiche Microcode Versionsnummer.

Und das Microcode Spectre Testscript prüft leider auch nur, ob ein neuer Microcode geladen wurde, aber nicht welcher.
D.h. mein Script zeigt jetzt immer noch die gleiche Version an:

HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0
    Update Signature    REG_BINARY    00000000BA000000

Also BA, anzeigen müsste er aber für meinen Skylake den Wert C2 wenn das Laden des neuen Microcode geklappt hätte.

D.h. der Schutz ist noch nicht aktiv.

Hier sagt jemand, dass das manuelle Updaten des Microcodes zu später ausgeführt wird und somit wirkungslos ist:
https://www.reddit.com/r/sysadmin/comments/7pe2ew/intel_spectre_microcode_update/dsgrjgi/

Entweder das, oder das Problem liegt daran, dass dieses manuelle Update den neuen microcode erst gar nicht lädt, wie mein Script zeigt.

Vielleicht sind die Einträge in der Registry aber auch veraltet, das könnte auch sein, wobei dann aber nicht dieser neue Schlüssel "Update Signature" nutzlos wäre.

Update:

Okay, also ich habe jetzt extre HWINFO installiert um zu prüfen, ob der Eintrag in der Registry korrekt ist und das ist er nicht.

Denn HWINFO64 zeigt nun an, dass der neue Microcode C2 (der alte war B2) geladen ist.
https://www2.pic-upload.de/img/34657007/microcode_after_manual_update.png

Das ganze nützt aber nichts, da Windows beim Booten noch vom alten Microcode ausgeht, wie der Typ bei reddit.com richtig sagte und die Patches gegen Spectre somit nicht aktiviert werden:

https://www2.pic-upload.de/img/34657039/spectre_test_after_manual_microcode_update.png

PS C:\Windows\system32> Get-SpeculationControlSettings
Speculation control settings for CVE-2017-5715 [branch target injection]
For more information about the output below, please refer to https://support.microsoft.com/en-in/help/4074629

Hardware support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: False
Windows OS support for branch target injection mitigation is disabled by system policy: False
Windows OS support for branch target injection mitigation is disabled by absence of hardware support: False

Speculation control settings for CVE-2017-5754 [rogue data cache load]

Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: True
Windows OS support for PCID performance optimization is enabled: False [not required for security]

Suggested actions

* Follow the guidance for enabling Windows Client support for speculation control mitigations described in https://supp
ort.microsoft.com/help/4073119

BTIHardwarePresent : True
BTIWindowsSupportPresent : True
BTIWindowsSupportEnabled : False
BTIDisabledBySystemPolicy : False
BTIDisabledByNoHardwareSupport : False
KVAShadowRequired : True
KVAShadowWindowsSupportPresent : True
KVAShadowWindowsSupportEnabled : True
KVAShadowPcidEnabled : False

PS C:\Windows\system32>

Das fette ist rot.

Das bedeutet also, den Microcode manuell unter Windows upzudaten bringt rein gar nichts.
Wenn man das tun will, dann müsste man das schon vor dem Booten von Windows machen.
Also entweder im BIOS oder im Bootloader (z.b. grub, keine Ahnung ob der das kann)

Zumindest gilt das solange, solange Microsoft selbst keine Möglichkeit bietet, den Microcode on the fly upzudaten.

Übrigens:
Gimp scheint jetzt recht lange zum Laden zu benötigen. Das fühlt sich wieder so an, als hätte man eine Festplatte anstatt einer SSD.

Diejenigen, die den Microcode schon mit dem Bootloader laden wollen, finden hier eine Lösung:

https://biosbits.org/

IT-Sicherheit ist und bleibt eine Illusion, leider. In einer Gesellschaft in der Geld regiert wird immer der Rotstift angesetzt werden müssen und dies triff immer zuerst Sachen wie Sicherheit und Dokumentation. Macht eine Firma dies nicht zu genüge geht sie unter.

Genug Ressourcen für Sicherheit bereitzustellen ist also kein IT, sondern in erster Linie ein gesellschaftliches Problem.

|()| schrieb:

IT-Sicherheit ist und bleibt eine Illusion, leider. In einer Gesellschaft in der Geld regiert wird immer der Rotstift angesetzt werden müssen und dies triff immer zuerst Sachen wie Sicherheit und Dokumentation. Macht eine Firma dies nicht zu genüge geht sie unter.

Genug Ressourcen für Sicherheit bereitzustellen ist also kein IT, sondern in erster Linie ein gesellschaftliches Problem.

Die Probleme hat man bei Open Source Projekten, die nicht an Gelder gebunden sind, genauso.

Das Problem steckt einfach darin, dass Cracker immer einen Schritt weiter sind, man nur nachdackeln kann, die Entwicklertools mit vielleicht ein paar Ausnahmen selten beim sicheren Entwickeln unterstützen und die Gesellschaft leider auch viel zu wenig für Sicherheitspatches interessiert, geschweige denn diese ernst nimmt und darunter sind sogar die Entwickler selbst dabei.

Vor ein paar Tagen habe ich bspw. bei 3 Open Source Projekten eine Sicherheitslücke gemeldet. Der Bugreport wurde zwar von den Entwicklern in den Bugreports gleich akzeptiert und gesagt dass man das fixen müsse, aber kein Projekt hat es geschafft, ein neues Release oder wenigstens ein Minorrelease rauszubringen.
Die Stableversionen, die man sich downloaden kann, sind somit weiterhin alle anfällig.
Von Sensibilität bezüglich Sicherheit keine Spur.

Da kommt noch was.
Spectre und Meltdown waren erst der Anfang.

https://skyfallattack.com/

So schnell wie es gekommen ist verschwand es auch wieder. Sollte es zu Angriffen kommen wird man was darüber berichten, doch der große Sturm ist vorbei.

Der Seitenbetreiber hat allerdings das Problem von Spectre und Meltdown gar nicht verstanden.

Spectre und Meltdown machen nicht die Runde, weil diese Angriffstechniken einen "Fancy" Namen haben, sondern weil die Bugs in der Hardware stecken und die Lücken somit nicht einfach reparierbar sind.

Bei einer Sicherheitslücke in Software schreibt man nen Patch und das Problem ist behoben.
Bei Hardware geht das nicht. Da hat man entweder Leistungseinbußen, weil ganze Betriebssysteme umgeschrieben werden müssen oder der Bug ist nicht wirklich reparierbar, man kann nur versuchen die Symptome beheben.
Das ist etwas völlig anderes, als "Fancy" Names.

Für vieles gibt es keine Patches, und jetzt werden die die es gibt auch noch zurückgezogen.
Linus Torvalds ist nicht der einzige der sich über die Situation, sagen wir mal, amüsiert.

Erhard Henkes

Welche Unternehmen werden von diesen Lücken mittelfristig profitieren?

Facebook, Google, Amazon, NSA, Sesamstraße, Frau Merkel.

hustbaer

Erhard Henkes schrieb:

Welche Unternehmen werden von diesen Lücken mittelfristig profitieren?

U.a. denke ich alle Hardwarehersteller, weil ja jetzt, überall dort wo die Patches eingespielt wurden/werden, für die selbe Workload mehr Hardware benötigt wird.

Erhard Henkes schrieb:

Welche Unternehmen werden von diesen Lücken mittelfristig profitieren?

Intel

Erhard Henkes

ja, das klingt logisch. genau der gleiche effekt wie bei den diesel cars.

hustbaer

Verstehe ich nicht. War das denn bei den Dieseln so? Oder war das Sarkasmus?

Die Situation ist IMO allerdings nicht ganz vergleichbar, denn bei Meltdown/Spectre hat keiner geschummelt und es sind quasi alle CPUs betroffen. Zumindest alle mit guter single threaded Leistung.

ARM profitiert weniger als Intel, denn niemand tauscht sein Tablet oder Smartphone wegen Spectre aus. Genausowenig wird man sich im Embeddedbereich darum Gedanken machen.

Bei den Cloudservern sieht das schon ganz anders aus, da müssen die Unternehmen zwingend die HW gegen neue austauschen. Zum einen um die Leistungsverschlechterung durch die Patches auszugleichen und zum anderen um sie mittelfristig gegen CPUs zu ersetzen, die nicht mehr fehleranfällig sind.
Und diese Domäne gehört eben den x86 CPUs und Intel ist ihr größter Produzent.

AMD wird zwar auch etwas vom Kuchen abkriegen, genauso wie es auch im Serverbereich sicher auch einige Spezialfälle für ARM CPUs gibt, aber das Groß an CPUs baut Intel, die können auch die Stückzahlen liefern.
AMD kann letzteres nicht und bei ARM ist der Servermarkt zu klein.

Ebenso wird Intel recht schnell Lösungen anbieten können, immerhin haben die gleich mehrere Entwicklerteams und Intel kann im Notfall auch gleich mehrere CPU Designs erforschen. AMD kann das nicht.
Und ARM könnte es zwar, aber den Servermarkt haben die noch nicht wirklich so bedient, dafür fehlt oft noch die Leistung.

Der ganz große Gewinner an Spectre und Meltdown ist somit Intel.

Den Vergleich zum Diesel finde ich unpassend. Denn da sind nur die Preise im Keller. Die Zukunft gehört kurzfristig eher den Benzinern und langfristig den E-Autos.

Gegen welche Hardware kann man denn tauschen?
Den Core i7 gegen i7-noSpectre?

Lukasi7 schrieb:

Gegen welche Hardware kann man denn tauschen?
Den Core i7 gegen i7-noSpectre?

Praktisch gegen keine, theoretisch gegen einen ARM Cortex-A53 oder ARM Cortex-A55.

Praktisch deswegen gegen keine, weil der ARM Cortex-A53 bzw. ARM Cortex-A55 Meilenweit von der Leistung eines Core i7 entfernt ist.
Aber wenn dir Sicherheit absolut wichtig ist und die Leistung vernachlässigt werden kann, dann wäre er eine Option.

Der ARM Cortex-A53 befindet sich bspw. im Raspberry Pi 3.
Sicher ist der deswegen, weil es sich um eine in-order CPU handelt, dies erklärt aber auch die geringe Leistungsfähigkeit.