Meltdown und Spectre – Revisited

Irritiert? Kann ich verstehen…

Aktuell besteht einige Verwirrung zu den ganzen Updates zur „Eindämmung“ von Meltdown und Spectre.

Im Folgenden möchte ich eine aktuelle Zusammenfassung liefern und genauer auf die Details in Windows (Server)-Systemen eingehen.

Patches für VMWARE

Neben dem Betriebssystem muss immer auch der Hypervisor (wenn vorhanden) und der CPU Microcode gepatcht werden.

Für den Hypervisor vSphere gibt es von VMWARE Patches:

https://www.vmware.com/us/security/advisories/VMSA-2018-0004.html

Wichtig hier: Es müssen alle ESXi Server und vCenter gepatcht werden.

VMWARE ist nur von Spectre betroffen, da der zur Ausnutzung der Meltdown Lücke relevante User Mode auf Ebene des vSphere Hypervisors keine Relevanz hat.

Spectre bezeichnet zwei Lücken. Um eine der beiden „einzudämmen“ braucht es immer zusätzlich ein Microcode Update für die CPU. VMWARE hatte bereits Microcode Updates von Intel erhalten und zusammen mit den eigentlichen Patches als getrenntes Update Paket veröffentlicht, dieses aber wieder zurückziehen müssen, da es laut Intel Probleme bei bestimmten Prozessoren damit geben kann. Intel hat die Möglichkeit von Problemen inzwischen auf alle CPU-Typen ausdehnen müssen. Aktuell sollten daher keine Microcode Updates über VMWARE bereitgestellt werden.

Neben dem Bezugsweg über VMWARE werden diese üblicherweise über BIOS Updates der PC/Server Hersteller eingespielt. Von Fujitsu sind die ersten Updates in KW5 zu erwarten:

https://sp.ts.fujitsu.com/dmsp/Publications/public/Intel-Side-Channel-Analysis-Method-Security-Review-CVE2017-5715-vulnerability-Fujitsu-products.pdf

Spectre ist wesentlich schwerer auszunutzen als Meltdown. Die Microcode Updates sind lediglich zur „Eindämmung“ einer der beiden Spectre Variante erforderlich.

Die Meltdown Lücke ist als kritischer einzustufen, da wesentlich leichter zu nutzen. Diese Lücke betrifft insbesondere das OS selbst. Angriffe sind also aufs Kernel-Daten im OS auf physischer Hardware oder auch innerhalb genau einer VM möglich – nicht etwa zwischen VMs. Diese Lücke kann nach aktuellem Stand durch alleiniges Einspielen eines Patches des OS Herstellers geschlossen werden. Dieser Patch bringt je nach CPU und OS einen Leistungsverlust mit sich. Dieser fällt bei neueren CPU-Typen geringer aus. Microcode Updates sollen diese Verbesserung auch für ältere CPU-Typen verfügbar machen. Für Meltdown haben diese Updates aber keinen Einfluß auf die Sicherheit.

In Summe ist daher das aktuelle Fehlen von Microcode Updates nicht ganz so kritisch, wie es erscheinen mag. Es sind auch noch keine aktiven Angriffe  bekannt geworden. Sobald stabiler Microcode verfügbar ist, sollte dieser auch eingespielt werden.

Patches für Windows

Für das korrekte „Eindämmen“ unter Windows ist es aber wesentlich, dass der Patch von Microsoft installiert und auch aktiviert wird. Das passiert leider nicht vollautomatisch. Daher möchte ich im Folgenden die Besonderheiten für den Anwendungsfall Windows diskutieren:

Microsoft hält aktuell Patches für folgende OS vor:

  • Windows 7
  • Windows 8.1
  • Windows 10
  • Windows 2008 R2
  • Windows 2012 R2
  • Windows 2016

OS außerhalb der Wartung (XP, 2003, Vista) werden nicht mehr versorgt.

Ebenso fehlen noch Windows 8, Windows 2008 und Windows 2012 (jeweils ohne R2), obwohl noch unter Wartung. Diese sollen nachgereicht werden.

Die Situation für Windows Client-OS kann man hier nachlesen:

https://support.microsoft.com/en-us/help/4073119/protect-against-speculative-execution-side-channel-vulnerabilities-in

Für die Server hält Microsoft diesen Artikel bereit:

https://support.microsoft.com/de-de/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution

Der Teufel im Detail

Da viele Virenscanner mit den Updates inkompatibel waren, muss zunächst am System ein Registry-Key gesetzt werden. Ohne diesen erscheinen die Updates nicht!

Aktuelle Virenscanner setzen diesen Key – je nach Hersteller – selbstständig.

Windows Defender als vollwertige Antivirus Lösung macht das auch, aber nur unter Windows 10 und 2016.

Bei den älteren Windows Systemen ist Windows Defender noch kein vollwertiger AV, sondern nur eine Malware Protection und setzt den Key daher auch nicht.

Systeme ganz ohne bzw. ohne im System sichtbaren Virenscanner – also z.B. hypervisorbasierte Lösungen wie TrendMicro DeepSecurity – setzen den Key ebenfalls nicht.

In all diesen Fällen muss der Key manuell oder via GPO gesetzt werden. Sonst erscheinen weder über Windows-Update noch über WSUS die nötigen Updates. Hier der entsprechende Befehl für die Commandline:

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat" /v "cadca5fe-87d3-4b96-b7fb-a231484277cc" /t REG_DWORD /d 0 /f

Einmal gesetzt, erscheint auch das Update – hier am Beispiel Server 2012 R2:

Besonderheit bei Windows Server OS

Im Server Artikel findet sich aber noch ein wesentlicher Punkt, der leicht übersehen werden kann:

Für Windows Server OS müssen zusätzlich drei weitere RegKeys gesetzt werden. Sonst ist der Patch zwar installiert, aber nicht aktiv!

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 0 /f

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization" /v MinVmVersionForCpuBasedMitigations /t REG_SZ /d "1.0" /f

Danach muss noch ein Reboot erfolgen.

Patchen ist gut. Kontrolle ist besser.

Unter Windows kann und sollte der erfolgte Patch über PowerShell verifiziert werden.

Für Windows 10 und Windows Server 2016 kann das entsprechende Skript aus einem Online-Repository geladen werden.

Im Folgenden die Befehle zur Installation und Ausführung in einer administrativen (!) PowerShell (Fragen jeweils mit Y/J beantworten):

Install-Module SpeculationControl

Set-ExecutionPolicy RemoteSigned

Import-Module SpeculationControl

Get-SpeculationControlSettings

Danach wird eine Auswertung angezeigt. Diese liefert eine Übersicht, ob Microcode UND Betriebssystem gegen die Lücken abgesichert sind.

Dabei wird auf Meltdown (CVE-2017-5754) und eine der beiden Spectre Lücken (CVE-2017-5715) eingegangen.

Es handelt sich dabei um genau die Spectre Lücke, die einen Microcode Update bedingt.

Auf meinem Microsoft Surface Book ist bereits das (vermutlich noch fehlerhafte – s.o.) Microcode Update aktiv. Es wird in diesem Sonderfall durch Microsoft via Windows Updates als BIOS Patch ausgeliefert.

Es sind alle Patches eingespielt. Der RegKey für die Patches wurde durch den Windows Defender gesetzt. Da ein Windows 10 läuft, muss kein weiterer Key zur Aktivierung gesetzt werden. Alle Zeilen sind grün:

Ganz anders sieht die Sache auf einer Windows 2012 R2 VM in einem VMWARE 6.0 Cluster aus.

Auf 2012 R2 gibt es keinen Online Provider für PowerShell Skripten. Daher muss das Skript manuell geladen (siehe Download am Ende des Artikels) und importiert werden:

Import-Module .\SpeculationControl.psd1

Get-SpeculationControlSettings

Auf dem verwendeten ESXi ist kein Microcode Update aktiv – daher auch nicht in den VMs.

Zunächst war der Patch in der getesteten VM auch nicht eingespielt, da die VM durch eine hypervisortbasierte AV Lösung geschützt wird und dadurch der nötige Registry-Key nicht automatisch gesetzt war. Daher wurde kein Update angezeigt und somit zunächst auch kein Patch aktiv– Iiiiiihhh, alles rot:

Nach dem Setzen des Registry-Keys für den Patch und der drei Registry-Keys zur Aktivierung (siehe oben) wird nach einem Reboot einiges grün:

Ohne Microcode bleibt es aber im Spectre Block noch größtenteils rot, da der Hardware Support (Microcode) zur vollständigen „Eindämmung“ fehlt.

Bei Meltdown ist alles grün, es fehlt aber auch hier der Hardware Support. Da dies aber hier nur Auswirkungen auf die Leistung und nicht die Sicherheit hat, ist diese Zeile als reine Information weiß dargestellt.

Anders auf dem nächsten Beispiel, einem physischen Windows 2016 Server. Hier kann das PowerShell Modul, wie bei Windows 10, über das Online-Repository installiert werden.

Da hier ein Windows Defender aktiv war und damit der RegKey für die Updates automatisch gesetzt wurde, war der Patch bereits Anfang Januar automatisch über Windows Updates installiert worden.

Trotzdem ist alles rot, weil die Patches nicht aktiviert waren. Es fehlten die 3 weiteren RegKeys.

Erst nach dem Setzen der Keys und einem Reboot wird wieder vieles grün.

Der Microcode und damit HW Support fehlt aber auch hier noch. Ein BIOS Update für diese Primergy RX2540M2 erscheint laut Fujitsu nächste Woche.

Hier sieht man aber schön, dass die CPU bereits neu genug ist, dass die „PCID performance optimization“, die den Leistungsverlust durch den Meltdown Patch verhindern soll, auch ohne Microcode Update verfügbar ist.

Management Summary

  • Auf allen Windows OS: RegKey zum Erhalt des Patches setzen, wenn der AV Scanner es nicht getan hat
  • Auf Windows Server OS: RegKeys zur Patch Aktivierung setzen (anbei ein umbenanntes Skript, das alle 4 Keys setzt)
  • Microcode Updates einspielen, sobald fehlerbereinigte verfügbar sind. Grund: Für Spectre ist der Schutz erst dann vollständig. Für Meltdown bleibt einem bei bestimmten CPUs mit dem neuen Microcode der Leistungsverlust erspart.
  • Hypervisor nach Vorgaben Patchen
  • Im System aktiv prüfen, ob die Lücke auf allen Ebenen geschlossen ist

Downloads

Batch zur Aktivierung aller 4 Registry-Keys zum Erhalt des Patches und zur Aktivierung auf Windows Server OS: ms-mitigation-activation-4servers

PowerShell Skript von Microsoft zur Prüfung unter Windows <=8.1  bzw. <=2012R2: SpeculationControl-PowerShellScript-Microsoft

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert