Eine neue Sicherheitslücke bei VMware und die Auswirkungen der neuen Lizenzpolitik

Der neueste Patch für VMware-Virtualisierungslösungen

Am 24.5.2024 wurde ein Patch für diverse Virtualisierungsprodukte veröffentlicht – von den eher Workstation-fokussierten Lösungen Workstation und Fusion bis hin zum vielleicht wichtigsten Produkt im VMware-Portfolio, dem ESXi-Hypervisor.

Schaut man sich die Patch-Notes an, so sieht man: Der Patch schließt einige Sicherheitslücken, die laut Common Vulnerability Scoring System (CVSS) als „hoch“ und auf der Webseite von Broadcom sogar als „kritisch“ eingestuft werden.

Besonders interessant (speziell für Angreifer) ist dabei die Tatsache, dass diese Sicherheitslücken einen Ausbruch aus der jeweils angegriffenen virtuellen Maschine erlauben und im schlimmsten Fall sogar zu Code-Ausführung auf dem physischen Host führen können. Das ist in einem stark konsolidierten Rechenzentrum keine schöne Vorstellung. Dieses Szenario wird dadurch abgeschwächt, dass zur Ausnutzung bestimmte andere Voraussetzungen erfüllt sein müssen.

Allerdings ist der Patch da, dann ist das doch alles kein Problem, oder? Nun ja, man muss hier zwei Aspekte berücksichtigen. Einer davon ist eine generelle Herausforderung in vielen IT-Abteilungen, der andere hat seinen Ursprung in der neuen Lizenzpolitik von Broadcom nach der Übernahme von VMware.

Aspekt 1: Einspielen von Updates

Ja, dass die Sicherheitsupdates verfügbar sind, ist natürlich sehr gut. Und man könnte meinen: Dann spiele ich die Updates halt morgen ein, und alles ist gut. Doch so einfach ist es mit einer in vielen Rechenzentren so zentralen Lösung wie einem Hypervisor nicht. Wenn hier etwas schiefgeht, kann das ein komplettes Unternehmen lahmlegen. Daher muss ein solches Update gut geplant und getestet werden. Das ist nichts Neues. Man testet das Update in einer möglichst abgeschotteten Umgebung und stellt sicher, dass die Umgebung danach noch (oder wieder) voll funktionsfähig ist. Das ist – abgesehen von der nötigen Arbeitszeit – zudem der einfachste Teil!

Danach braucht man ein Wartungsfenster, in dem man das Update einspielen kann. Und hier wird es schon spannender, da vieles Einfluss auf die Terminierung und vor allem die Dauer des Wartungsfensters haben kann. Ganz besonders wichtig ist dabei die Frage, ob ich alle Systeme abschalten und gleichzeitig patchen kann. Wenn ja, verkürzt das das Wartungsfenster natürlich signifikant. Aber was, wenn doch etwas schiefläuft? Die Dauer eines möglichen Rollbacks muss eingeplant werden. Andererseits: Kann ich die Systeme nur nacheinander patchen, dauert der Patchvorgang zwar länger, jedoch ist das Risiko für einen Ausfall der Umgebung sehr gering. Angenommen, es existieren Redundanzen und die Umgebung ist nicht zu 100 % ausgelastet, so kann ich nacheinander die virtuellen Maschinen von einem Host zu anderen Hosts migrieren und den jetzt „leeren“ Host patchen. Ist dieser wieder fertig gepatcht, gehe ich zum nächsten Host und wiederhole das Vorgehen so lange, bis alle Hosts gepatcht sind. Natürlich hängt die Umsetzbarkeit dieses Verfahrens auch von der Anzahl der Hosts ab. Bei großen Unternehmen ist es wahrscheinlich, dass Ressourcen und Redundanzen etwas großzügiger dimensioniert sind und ich die beiden Ansätze (sinnvoll) kombinieren kann.

Wird VMware in großem Stil eingesetzt, bin ich hier auf der sicheren Seite, und die Patches sind für mich auch verfügbar. Doch wie ist vorzugehen, wenn ich bisher mit wenigen, einzeln gemanagten Servern und der kostenlosen Version von ESXi ausgekommen bin?

Aspekt 2: Die Updates sind für die kostenlose Version nicht (mehr) verfügbar

Mit der Umstellung der Lizenzierung durch Broadcom und dem damit einhergehenden Ende der kostenlosen ESXi-Version erhält man für diese keine Updates mehr. Unabhängig von der Häufigkeit, mit der man die kostenlose Version aktualisiert hat, war dies gerade in kleinen Umgebungen wenig problematisch. Man setzt ein Wartungsfenster an, aktualisiert ESXi – im Zweifelsfall per Update von einem Boot-Stick – und das Update war fertig.

Doch das ist jetzt nicht mehr möglich. Das bedeutet: Alle, die mit dem kostenlosen ESXi-Server ausgekommen sind, stehen aktuell ziemlich verloren da und müssen sich überlegen, wie sie mit der Situation umgehen. Dabei gibt es im Grunde genommen nur drei Möglichkeiten:

1. Man akzeptiert, dass die Sicherheitslücke existiert und betet, dass sie nicht ausgenutzt wird. Das ist die schlechteste Option und ist nur der Vollständigkeit halber angegeben und sollte definitiv nicht die „Lösung“ sein.
2. Man lizenziert die kleinste Variante des VMware-Stacks, der aktuell verfügbar ist, d.h. vCenter, ESXi und einige weitere Komponenten. Klar, man erhält dann die Updates, doch sind die Kosten für viele kleine Unternehmen und gerade beim Einsatz eines einzelnen Servers nicht besonders attraktiv.
3. Man bewegt sich von VMware weg und migriert zu einem anderen Hypervisor. Das ist die vielleicht zukunftssicherste Möglichkeit. Sie ist allerdings mit erheblichem Aufwand verbunden: Welche Lösung setze ich ein? Wie migriere ich meine aktuellen virtuellen Maschinen? Werden alle virtuellen Maschinen von ihren Herstellern auch auf dem neuen Hypervisor unterstützt?

Dieser Aspekt ist nicht selbstverständlich und eindeutig durch die Politik von Broadcom verursacht. Ein interessanter Nebeneffekt: Viele angehende ITler und Administratoren mit eigenem kleinem Server zuhause werden spätestens jetzt zu anderen Lösungen migrieren müssen und privat kein VMware-Know-how mehr aufbauen. Das ist aktuell kein großes Problem für VMware. Wenn jedoch die nächste Generation der Administratoren in Technologie-Entscheidungen einbezogen wird, wird sie Lösungen bevorzugen, mit denen sie bereits vertraut ist. Und aufgrund der neuen Lizenzpolitik von Broadcom wird es in den meisten Fällen nicht ESXi sein.

Fazit

Broadcom hat sich mit dem Ende des kostenlosen ESXi-Servers keinen Gefallen getan. Das, was jetzt passiert ist, war nur eine Frage der Zeit, es musste früher oder später so kommen. Und leider war es eher früher. Das bedeutet, dass sich die Nutzer des kostenlosen ESXi-Servers jetzt nach Alternativen umsehen oder tief in die Tasche greifen müssen, was der Beliebtheit von VMware nicht zuträglich sein wird.