VMware veröffentlicht Patches für Foreshadow-NG (CVE-2018-3646)

VMware veröffentlichte am 14.08.2018 Updates für vCenter und ESXi Server. Diese Updates sollten näher beleuchtet werden, da sie die Foreshadow-NG Lücke in Intel Prozessoren schließt und gegebenenfalls Performanceprobleme verursachen können. Es handelt sich dabei um einen CPU Bug der Spectre / Meltdown Familie. Genauer eingeordnet ist es eine der 8 Spectre-NG Lücken, über die mein Kollege Martin Steigerwald bereits einen Artikel auf unserem Blog veröffentlicht hat. Eine aktuelle Auflistung der bekannten Bugs findet sich auch in diesem Heise Artikel. Hier erfahren Sie, ob Sie updaten sollten. 

Kann / sollte ich updaten?

Grundlegend: Ja. Betroffen sind alle ESXi Versionen. Die Patches wurden für die supporteten Versionen 6.0, 6.5 und 6.7 veröffentlicht und enthalten neben den eigentlichen VMware Patches auch den Intel CPU microcode. Nach erfolgreicher Installation der oben genannten VMware Updates/Patches, befindet man sich auf folgenden neuen ESXi Build Numbern (sind Stand 2018-08-23 noch nicht im VMware KB Artikel gelistet)

ESXi 6.0: 9313334
ESXi 6.5: 9298722
ESXi 6.7: 9484548

Im vSphere Client erhält man allerdings folgende Fehlermeldung:

„The host is potentially vulnerable to issues described in CVE-2018-3646“

Im Desktop Client lautet die Fehlermeldung „esx.problem.hyperthreading.unmitigated“:

Mittels der Patches wurde der CPU Microcode installiert, der einen der Angriffsvektoren (Sequential-context attack vector) unterbindet. Dieser Schutzmechanismus wird automatisch aktiviert, da keine signifikanten Performanceeinbußen zu erwarten sind. Entscheidender ist aber der Angiffsvektor „Concurrent-context attack vector“. Dieser kann nach inoffiziellen Informationen die CPU Performance um bis zu 30% negativ beeinflussen. Dies ist auch der Grund, warum der Schutz für dieses Szenario mittels Patches nicht automatisch aktiviert wird & die Fehlermledung erscheint.

Concurrent-context attack vector – was kann / muss ich tun?

Es gibt 2 Möglichkeiten:

  1. man ignoriert die Sicherheitslücke & „unterdrückt“ die Warnmeldung
  2. man aktiviert das neu implementierte Sicherheitsfeature von VMware

Im entsprechenden VMware KB Artikel sind die Lösungswege erläutert. VMware empfiehlt Lösungsweg 2.

Der Lösungsweg für Möglichkeit 1 ist schnell erklärt:
Man setzt in den ESXi Servern in den Advanced System Settings die Variable „UserVars.SuppressHyperthreadWarning“ (Default 0) auf 1. Somit verschwindet die Meldung.

Bei Möglichkeit 2 wird es etwas komplizierter:
Man muss zuerst beurteilen, ob man genügend CPU-Headroom, also freie Ressourcen, zur Verfügung hat.

Wenn Sie bereits Performance Monitoring Tools wie z.B. Veeam One im Einsatz haben, können Sie anhand der gesammelten Daten entscheiden. Die CPU Auslastung des Clusters bzw. der einzelnen Hosts sollte dauerhaft unter 70% sein. Hierbei sollten auch Performance Peaks berücksichtigt werden. Sollten Sie noch keine Software für das Monitoring einsetzen können Sie das HTAware Mitigation Tool von VMware einsetzen.  Dieses Powershell Skript greift auf die im VMware vCenter gesammelten Performance Daten zurück und erzeugt einen HTML Report wie diesen:

In diesem Beispiel wurden keine Performance-Engpässe gefunden und der „ESXi Side-Channel-Aware Scheduler“ kann aktiviert werden. Um die ESXi Server vollständig abzusichern, muss ein Advanced System Setting angepasst werden. In diesem Fall muss der Parameter „VMkernel.Boot.hyperthreadingMitigation“ vom Defaultwert „false“ auf „true“ geändert werden.
Um den neuen „ESXi Side-Channel-Aware Scheduler“ zu aktivieren, ist ein Neustart des ESXi Servers nötig. Im Anschluss an den Reboot ist die Meldung verschwunden.

Sollten Sie Fragen zur Sicherheitslücke haben oder Hilfe bei der Aktualisierung ihrer VMware Infrastruktur benötigen, kontaktieren Sie uns. Wir helfen gerne weiter.

 

Literaturverzeichnis

Aufgrund der großen Menge an Quellen und Informationen hier eine gesammelte Liste von Infos, die in diesen Artikel eingeflossen sind:

Daniel Harenkamp

Daniel ist seit November 2015 bei der Proact Deutschland beschäftigt. Er ist als Professional Services Engineer im Bereich NetApp Hard- und Software, Virtualisierung und Backup unterwegs. Ob das Backup mit Commvault, Veeam oder den NetApp Produkten durchgeführt wird spielt für ihn dabei keine Rolle. Seine Kenntnisse den angrenzenden Gebieten wie z.B. der Microsoft Produktpalette sind ihm bei seiner Tätigkeit sehr hilfreich. Wenn dann noch Zeit bleibt ist er auch als Trainer tätig.

 
Kommentare

Hallo Daniel, ich habe gerade Variante 2 versucht, danach bootet mein ESXi 6.0 nicht mehr, es bleibt bei „initializing scheduler“ am Bootscreen hängen. Konnte gottseidank via SHIFT + R noch auf eine ältere Version zurück um esxi wieder zu booten.

Hast du ne Idee?

Daniel Harenkamp
Daniel Harenkamp

Hallo Mike,

der Fehler ist mir schon mal über den Weg gelaufen.
Probier mal im Bios des Hosts „legacy USB“ zu deaktivieren.
Dazu gibt es auch einen VMware KB: https://kb.vmware.com/s/article/2077712

Gruß
Daniel

Hi Daniel,

den KB Artikel hab ich auch direkt gefunden, hat aber nichts geholfen. Das Flag was man mit Option 2 ja aktiviert, führt ja dazu, dass ein anderer Scheduler geladen wird, soweit hab ich den Artikel bei VMWare verstanden.

Der USB Legacy Artikel ist ja schon Jahre Alt, ggf. gibt es jetzt ein neues Problem? Nutze ein VMWare zertifiziertes SuperMicro Board, und auch ansonsten nur zertifizierte HW, daran sollte es also eigentlich nicht liegen 🙁

Danke & Grüße
Mike

Daniel Harenkamp
Daniel Harenkamp

Hi,

ohne das System direkt zu sehen wird es dann natürlich schwer eine Diagnose zu machen.

Du kannst noch versuchen, BIOS und alle anderen Firmwares zu aktualisieren. Da die Patches von VMware CPU Microcodes mitbringen könnte es sein, dass deine BIOS Version das nicht unterstützt.
Zusätzlich kannst du noch testen, ob das Abschalten von Hyperthreading im Bios hilft.

Ansonsten muss man in die Logs schauen, an was er sich tatsächlich verschluckt.

Grüße
Daniel

Danke dir Daniel.

So wie es aussieht schreibt er noch kein Log beim Laden des Schedulers, die Logs sind nämlich leer beim Bootvorgang.

Ich versuche mal das BIOS Update

Hinterlassen Sie einen Kommentar an Mike