Spectre und Meltdown

Gibt es eigentlich unter Windows irgendeine Möglichkeit für den Anwender, dass er den CPU Microcode on the fly updated?

Also ohne erst das BIOS updaten zu müssen oder den microcode im Grub Bootloader zu laden?

Bei meinem Windows fehlt nämlich noch das Update für den Microcode, damit der Schutz gegen Spectre Variante 2 aktiv wird.

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: False
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: True

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

* Install BIOS/firmware update provided by your device OEM that enables hardware support for the branch target injectio
n mitigation.

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

Das fette ist rot.

Für Spectre Variante 2 ist mein System unter Windows also noch anfällig.
Meltdown geht nicht mehr.

Übrigens, hier ist noch ein weiteres Tool mit dem man die Sicherheit des Systems ebenfalls bezüglich Meltdown und Spectre Variante 2 testen kann:

https://www.heise.de/download/product/specucheck

Wer das PowerShell Script ausführen möchte, der muss unter Windows 7 übrigens erst einmal schauen, ob er eine aktuelle PowerShell Version hat.
Das geht in der PowerShell mit dem Befehl

get-host

Steht da bei Version eine 2 dran, dann ist die zu alt für das Spectre und Meltdown Testscript.
Um die Powershell upzudaten muss man aber erst einmal das .NET Framework 4.5 installieren, das ist nämlich für das Windows Management Framework 5.1 notwendig, die wiederum die PowerShell enthält.

Anschließend kann man eine neue PowerShell Version installieren, in dem man das Windows Management Framework 5.1 installiert
https://www.microsoft.com/en-us/download/details.aspx?id=54616

Windos 7 64 Bit Nutzer brauchen hier die Datei:
Win7AndW2K8R2-KB3191566-x64.zip

Ist alles installiert, dann sollte das Testscript in einer PowerShell mit Adminrechten funktionieren.

okay, hier gibt's ne Anleitung:

http://forum.notebookreview.com/threads/how-to-update-microcode-from-windows.787152/

Das AMD Tool:
https://web.archive.org/web/20160320110218/http://www.amd64.org/microcode/amd-ucode-latest.tar.bz2

Intel Microcode:
https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File

Wichtig, ihr benötigt beides.
Also auch das AMD Zeugs wenn ihr eine Intel CPU habt.
Im AMD Zeugs ist das dafür notwendige Tool enthalten.

Haswell, Broadwell und IvyBridge Besitzer sollten mit dem Update des Microcodes übrigens noch warten.
Da sind noch Fehler drin, die erst gefixt werden müssen.

Skylake Nutzer und später können das Microcode Update einspielen.

Außerdem muss es bei jedem Neustart geladen werden, falls es bei euch noch nicht im BIOS enthalten ist, es empfiehlt sich also in Autostart ein Skript zu starten, das das bewerkstelligt.

Irgendwie habe ich das Gefühl es herrscht nur noch Chaos. Die Informationspolitik der Hersteller und Unternehmen (Vorwiegend US-Firmen) ist erbärmlich zu diesem Thema und die Updates sind im Zuge der Sicherheit eine Verbesserung (Eher eine Grunderwartung!), doch eine Handbremse...

Ich habe mit Kollegen bei uns im Rechenzentrum selber auf mehreren Servern die Microcodes und Updates eingespielt und eines weiß ich jetzt schon: Die Rechnung wird hoch, da die Leistung sinkt. Das wird sich im PnL richtig zeigen...

Doch ich freue mich, dass ich hier nicht der einzige bin der leidet

Eben gefunden - wenn ihr mal zu dem Thema wenigstens mal etwas lachen wollt: https://www.it-madness.com/posts/531/

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