log4j und die vCenter-Version, die es nie gab

Was von der Überschrift her klingt wie das neueste Abenteuer der Harry Potter – Reihe, war für mich tatsächlich eher ein Ärgernis. Doch von vorne:

Wie die meisten sicherlich mitbekommen haben, gab es ja ziemlichen Wirbel um das Update 3 von VMware vSphere 7.0. Heiß beworben von VMware wurde es Anfang Oktober 2021 zum Download bereitgestellt, kurz darauf kam schon Update 3a, nur um Mitte November durch Update 3b ersetzt zu werden – welches dann nach nur wenigen Tagen komplett zurückgezogen wurde! *seufz*

Was man dazu wissen muss, wurde in dieser FAQ zusammengefasst:
https://kb.vmware.com/s/article/86398

Nun kam der 11. Dezember 2021 und damit der große Spaß mit der Sicherheitslücke CVE-2021-44228 in log4j, die leider eine riesige Anzahl an professionellen Softwareprodukten – z.B. auch das VMware vCenter – angreifbar machte. Workarounds veröffentlichte VMware in seiner Knowledgebase hier: https://kb.vmware.com/s/article/87081

Diese waren ursprünglich für die Versionen 7.0 GA bis einschließlich 7.0Update 3a gelistet.
Und was ist mit 3b?

Ja, das Update wurde zurückgezogen – aber es WAR vorher verfügbar und ich hatte einen Kunden, bei dem dieses auch tatsächlich implementiert worden war.

Das Naheliegendste war, den Workaround für 7.0 U3 und U3a zu implementieren. Gesagt, getan, jedoch starteten einige Dienste nach Anpassung der Datei /usr/lib/vmware-vmon/java-wrapper-vmon nicht mehr:

_{Service-control failed. Error: Failed to start services in profile ALL. RC=2, stderr=Failed to start eam, lookupsvc services. Error: Service crashed while starting}

Die Lösung dafür war dann jedoch zum Glück doch relativ einfach. Während im oben erwähnten KB-Artikel zu den Dateiberechtigungen die folgenden Kommandozeilen

_{chown root:cis /usr/lib/vmware-vmon/java-wrapper-vmon
chmod 754 /usr/lib/vmware-vmon/java-wrapper-vmon}

gelistet waren, war tatsächlich auch das Gruppenschreibrecht notwendig:

_{chmod 774 /usr/lib/vmware-vmon/java-wrapper-vmon}

Damit konnten dann alle Dienste wieder gestartet werden und der Workaround war implementiert.

UPDATE: Während des Verfassens dieses Artikels fiel mir auf, dass der KB-Artikel nun tatsächlich auch das Update 3b explizit erwähnt. Die Dateiberechtigungen werden allerdings nach wie vor nur mit 754 gelistet, so dass dieser Blog vielleicht doch für den ein oder anderen hilfreich sein könnte.