VxRail: Manager behebt die Sicherheitslücke von Apache Log4Shell (CVE-2021-44228, CVE-2021-45046)

Die Apache Software Foundation hat Informationen zu einer kritischen Sicherheitslücke in der Apache Log4j-Bibliothek bezüglich Remote-Codeausführung veröffentlicht, die laut GitHub Advisory Database als Log4Shell bekannt ist (auch detailliert in CVE-2021-44228, CVE-2021-45046 und CVE-2021-4104). VxRail Manager ist dem in der Sicherheitslücke beschriebenen Problem ausgesetzt.
 

Weitere Informationen zu diesen CVEs finden Sie in den folgenden Artikeln:

• Sicherheitslücke bei Apache Log4j.
• CVE-2021-45046 (Log4j 2.15)
• CVE-2021-4104 (Log4j 1.2)

Im vorherigen Skript wurde ein weiteres Problem entdeckt, das dazu führen kann, dass eine betroffene Datei auf VxRail Manager aus einem Systemarchiv wiederhergestellt wird. Auch dieses Problem wurde in dieser Version behoben.

Wenn Sie frühere Skripte verwendet haben, die mit diesem Artikel bereitgestellt wurden, laden Sie das neueste Skript (1.1.2) herunter und führen Sie es auf VxRail Manager aus, um sicherzustellen, dass Sie über die vollständige Korrektur verfügen.
 

Anforderungen und Umfang

Der Umfang der in diesem Artikel beschriebenen Abhilfemaßnahmen umfasst folgende Punkte:

• Dieser Artikel gilt für VxRail Manager in den Versionen VxRail 4.5.x, 4.7.x und 7.0.x sowie für VxRail Manager in den Versionen VCF 3.x und 4.x.
• Mit dem Skript und den angegebenen Korrekturschritten wird die Sicherheitslücke nur in der VxRail Manager-Appliance-VM behoben.
• Andere Komponenten außerhalb von VxRail Manager wie vCenter Server Appliance (vCSA), NSX usw. müssen separat gemindert werden und sind nicht in diesem Skript enthalten.
• Außerdem werden mit dem Skript keine Anwendungen oder Dienste korrigiert, die innerhalb von VMs ausgeführt werden und der Sicherheitslücke ausgesetzt sein können. Dell Technologies empfiehlt allen Kunden, sich bei ihren Anwendungs- oder Softwareanbietern nach Services zu erkundigen, die in VMs ausgeführt werden, um sicherzustellen, dass sie nicht beeinträchtigt werden.

Links zu betroffenen VMware-Produkten und potenzielle Problemumgehungen finden Sie im folgenden VMware VMSA-Artikel:

• VMware Sicherheitshinweis VMSA-2021-0028

VMware stellt ein Skript zur Automatisierung der Korrektur in der vCenter Server-Appliance im folgenden Artikel bereit:

• Python-Skript zur Automatisierung der Schritte zur Problemumgehung für die Sicherheitslücke VMSA-2021-0028 auf vCenter Server-Appliance (87088)

An diesen Artikel angehängt ist eine Datei fixlog4j-CVE-2021-44228-CVE-2021-45046-v-1-1-2.zip , enthält nur das Skript für VxRail Manager.
 

VxRail-Versionen mit enthaltener Korrektur

Dieses Problem wurde in den folgenden VxRail-Softwareversionen behoben:

• VxRail-Paketsoftwareversion 7.0.320
• VxRail-Appliance-Softwareversion 4.7.541
• VxRail-Appliance-Softwareversion 4.5.471

Es wird empfohlen, ein Upgrade auf eine VxRail-Softwareversion durchzuführen, die die Korrektur enthält.
Das Skript wird für Kunden empfohlen, die nicht sofort ein Upgrade durchführen können.

Hinweis: Wenn Ihr VxRail-7.0.xxx-Cluster von einem vom Kunden gemanagten vCenter verwaltet wird, finden Sie im folgenden Artikel zusätzliche Überlegungen, die möglicherweise zutreffen:

• VxRail: Das Upgrade von vCenter auf 7.0 U3c oder höher schlägt aufgrund eines potenziellen Treiberkonflikts fehl

Zusätzliche Überlegungen zu Legacy-Patching-Skripten:

Wenn Sie zuvor ein früheres Aktualisierungsskript ausgeführt haben (älter als fixlog4j-CVE-2021-44228-CVE-2021-45046-v-1-1-2.zip) auf dem VxRail Manager beachten Sie Folgendes:

• • Dieses Skript erstellt Sicherungskopien der ursprünglichen JAR-Dateien mit der Erweiterung ".bak" und speichert sie in den ursprünglichen Bibliotheksverzeichnissen.

  • Diese .bak Dateien können nach dem Upgrade auf VxRail 8.0.380 oder höher Probleme beim Servicestart verursachen, da sie fälschlicherweise zusammen mit aktiven Dateien im selben Verzeichnis geladen werden.

Führen Sie die folgenden Schritte aus, um Legacy-.bak-Dateien zu verschieben und einen normalen Systembetrieb sicherzustellen:

1. Auf vorhandene .bak Dateien prüfen
   • find /mystic/connectors -name "log4j-core*.bak"
2. Wenn .bak Dateien gefunden werden, verschieben Sie sie an einen sicheren Speicherort:
   • mkdir -p /tmp/log4jbak
   • find /mystic/connectors -name "log4j-core*.bak" -type f -exec mv {} /tmp/log4jbak/ \;
3. Check.bak Dateien, die nicht vorhanden sind in /mystic/connectors Ordner und starten Sie den Service neu:

• • Szenario A – Wenn Sie das LCM-Upgrade noch NICHT durchgeführt haben:
    • Fahren Sie mit dem LCM-Upgrade fort. Beim Upgradeprozess werden automatisch alle Services neu gestartet.

• • Szenario B – Wenn Sie das LCM-Upgrade BEREITS abgeschlossen haben und ein VC-Plug-in-Fehler auftritt:
    • Starten Sie VxRail Manager neu:
      • systemctl restart vmware-marvin
      • service runjars restart

Korrekturschritte

Führen Sie die folgenden Schritte aus, um die Probleme zu beheben:

1. Laden Sie die fixlog4j-CVE-2021-44228-CVE-2021-45046-v-1-1-2.zip Datei, die diesem Artikel beigefügt ist.
2. Laden Sie die .zip-Datei mit Nutzername „mystic“ über SCP auf den VxRail Manager hoch (WinSCP ist z. B. ein SCP-Client, der verwendet werden kann).
3. Melden Sie sich mit dem Nutzer mystic bei der VxRail Manager-VM-Konsole oder SSH an. 
4. Wechseln Sie in das Verzeichnis, in das Sie die .zip Datei hochgeladen haben, und extrahieren Sie sie mit dem Befehl "unzip":

   mystic@vxrm:~> unzip fixlog4j-CVE-2021-44228-CVE-2021-45046-v-1-1-2.zip
   Archive:  fixlog4j-CVE-2021-44228-CVE-2021-45046-v-1-1-2.zip
     inflating: fixlog4j-CVE-2021-44228-CVE-2021-45046.sh

5. Machen Sie das Skript mit dem Befehl chmod ausführbar:

   mystic@vxrm:~> chmod +x fixlog4j-CVE-2021-44228-CVE-2021-45046.sh

6. Melden Sie sich mit dem Befehl su als VxRail Manager-Root-Nutzer an:

   mystic@vxrm:~> su -
   Password:

7. Stellen Sie sicher, dass Sie sich im selben Verzeichnis befinden, in das Sie das Skriptpaket extrahiert haben:

   vxrm:~ # cd /home/mystic
   vxrm:/home/mystic #

8. Führen Sie das Skript aus:

   vxrm:/home/mystic # ./fixlog4j-CVE-2021-44228-CVE-2021-45046.sh

   Beispiel für eine Skriptausgabe:

   Stop MARVIN and runjars service before patching the system
   
   /mystic/connectors/eservice/lib/log4j-core-2.13.0.jar is affected by CVE-2021-44228 and CVE-2021-45046, need to apply patch
   patching /mystic/connectors/eservice/lib/log4j-core-2.13.0.jar
   Successfully patched /mystic/connectors/eservice/lib/log4j-core-2.13.0.jar
   
   /mystic/connectors/cluster/lib/log4j-core-2.13.0.jar is affected by CVE-2021-44228 and CVE-2021-45046, need to apply patch
   patching /mystic/connectors/cluster/lib/log4j-core-2.13.0.jar
   Successfully patched /mystic/connectors/cluster/lib/log4j-core-2.13.0.jar
   
   To ensure there is no reload behavior, we need to pack the .war file as well.
   looks like /usr/lib/vmware-marvin/marvind/webapps/ROOT.war contains the bad log4j-core library WEB-INF/lib/log4j-core-2.13.0.jar
   Archive:  /usr/lib/vmware-marvin/marvind/webapps/ROOT.war
     inflating: WEB-INF/lib/log4j-core-2.13.0.jar
   Patching WEB-INF/lib/log4j-core-2.13.0.jar in /usr/lib/vmware-marvin/marvind/webapps/ROOT.war
   Repack /usr/lib/vmware-marvin/marvind/webapps/ROOT.war
   updating: WEB-INF/lib/log4j-core-2.13.0.jar (deflated 11%)
   Clean up the ROOT folder...
   
   Always apply a reboot of MARVIN and runjars services
   restart MARVIN
   MARVIN restart successfully
   restart runjars
   runjars restart successfully

    

Warten Sie mindestens 10 Minuten, wenn Sie einen der folgenden manuellen Validierungsschritte durchführen möchten.

Je nach Version von VxRail Manager gibt es verschiedene Versionen der lib4j-core-Bibliothek.

Das Skript wurde entwickelt, um VxRail Manager unabhängig von der Version von lib4j-core, die in dieser Version von VxRail Manager enthalten ist, korrekt zu korrigieren.

Die obige Ausgabe aus dem Ausführen des Skripts kann je nach enthaltener Version von lib4j-core verschiedene Dateien anzeigen, die aktualisiert werden.
 

In VxRail finden Sie Links zu VMware-Artikeln, die Workarounds für ihre Produkte und Korrekturen abdecken: Informationen zu Log4Shell (CVE-2021-44228/CVE-2021-45046/CVE-2021-4104) und VxRail-Umgebungen
 

Validierungsschritte

Um das Problem zu beheben, entfernt das Skript die Datei JndiLookup.class aus den lib4j-core-* jar-Dateien.

Eine jar-Datei ist ein Java-Paketformat, das mehrere Klassen, Metadaten und andere Java-Programme in einer einzigen Datei enthält. Es ähnelt dem Konzept einer ZIP-Datei und basiert auf dem .zip-Format. Bei der Skriptausführung wird überprüft, ob jede JAR-Datei erfolgreich aktualisiert wurde.

Um eine manuelle Validierung durchzuführen, ob das Skript funktioniert hat, können Sie überprüfen, ob die log4j-core-* JAR-Dateien, die in VxRail Manager vorhanden sind, enthalten weiterhin die betroffene JndiLookup.class-Datei . Wenn es funktioniert hat, sollte keine Ausgabe für die folgenden Befehle angezeigt werden, was die betroffenen JndiLookup.class Die Datei ist nicht mehr in der JAR-Datei vorhanden.
 

Validierung mit automatisiertem Befehl 

Der folgende Befehl kann auf VxRail Manager ausgeführt werden, um nach allen log4j-core-xxxx.jar Dateien, die auf VxRail Manager vorhanden sind, prüfen Sie, ob sie die betroffenen JndiLookup.class Datei:

vxrm:/home/mystic # for myfile in `find / -name log4j-core*jar -print |grep -v log4jbak`; do echo $myfile; unzip -l $myfile | grep JndiLookup.class; done

Beispielausgabe (aktualisiertes System):

/mystic/connectors/eservice/lib/log4j-core-2.13.0.jar
/mystic/connectors/cluster/lib/log4j-core-2.13.0.jar
/usr/lib/vmware-marvin/marvind/webapps/ROOT/WEB-INF/lib/log4j-core-2.13.0.jar

Im obigen Beispiel wird die JndiLookup.class Die Datei ist in der JAR-Datei nicht vorhanden, daher hat das Skript funktioniert und die Überprüfung war erfolgreich.

Nachfolgend finden Sie eine Beispielausgabe eines betroffenen Systems, das aktualisiert werden muss:

/mystic/connectors/eservice/lib/log4j-core-2.13.3.jar
     2892  2020-05-10 12:08   org/apache/logging/log4j/core/lookup/JndiLookup.class
/mystic/connectors/cluster/lib/log4j-core-2.13.3.jar
     2892  2020-05-10 12:08   org/apache/logging/log4j/core/lookup/JndiLookup.class
/usr/lib/vmware-marvin/marvind/webapps/ROOT/WEB-INF/lib/log4j-core-2.13.3.jar
     2892  2020-05-10 12:08   org/apache/logging/log4j/core/lookup/JndiLookup.class

Im obigen Beispiel sind die JndiLookup.class Datei ist noch im Ordner log4j-core-2.13.3.jar jar-Datei.

Nachfolgend finden Sie eine Beispielausgabe eines Systems mit einem korrigierten oder aktualisierten log4j-core Bibliothek, in der die JndiLookup.class Datei kann ignoriert werden:

/usr/lib/vmware-marvin/marvind/webapps/ROOT/WEB-INF/lib/log4j-core-2.17.1.jar
     3158  2021-12-27 17:30   org/apache/logging/log4j/core/lookup/JndiLookup.class
/mystic/connectors/eservice/lib/log4j-core-2.17.1.jar
     3158  2021-12-27 17:30   org/apache/logging/log4j/core/lookup/JndiLookup.class
/mystic/connectors/cluster/lib/log4j-core-2.17.1.jar
     3158  2021-12-27 17:30   org/apache/logging/log4j/core/lookup/JndiLookup.class

Im obigen Beispiel sehen Sie die JndiLookup.class Datei in der Ausgabe, aber die Korrektur für das Problem befindet sich in log4j-core-2.17.1.jar.

 

Validierung mit manueller Überprüfung jeder Datei

So identifizieren Sie schnell alle log4j-core-xxxx.jar auf VxRail Manager vorhanden sind, führen Sie den folgenden Befehl aus (dadurch wird auch die Ausgabe in einen nutzbaren Befehl formatiert):

vxrm:/home/mystic # find / -name log4j-core*jar -print |grep -v log4jbak | awk '{print("unzip -l " $1 "|grep JndiLookup.class")}'

Beispielausgabe:

unzip -l /mystic/connectors/eservice/lib/log4j-core-2.13.0.jar|grep JndiLookup.class
unzip -l /mystic/connectors/cluster/lib/log4j-core-2.13.0.jar|grep JndiLookup.class
unzip -l /usr/lib/vmware-marvin/marvind/webapps/ROOT/WEB-INF/lib/log4j-core-2.13.0.jar|grep JndiLookup.class

Führen Sie in der obigen Beispielausgabe jeden Befehl manuell aus, um festzustellen, ob die betroffenen JndiLookup.class Datei:

vxrm:/home/mystic # unzip -l /mystic/connectors/eservice/lib/log4j-core-2.13.0.jar|grep JndiLookup.class
vxrm:/home/mystic #

vxrm:/home/mystic # unzip -l /mystic/connectors/cluster/lib/log4j-core-2.13.0.jar|grep JndiLookup.class
vxrm:/home/mystic #

vxrm:/home/mystic # unzip -l /usr/lib/vmware-marvin/marvind/webapps/ROOT/WEB-INF/lib/log4j-core-2.13.0.jar|grep JndiLookup.class
vxrm:/home/mystic #

Im obigen Beispiel ist die JndiLookup.class Die Datei ist in der JAR-Datei nicht vorhanden, daher hat das Skript funktioniert und die Überprüfung war erfolgreich.
 

vxrm:/home/mystic # unzip -l /mystic/connectors/cluster/lib/log4j-core-2.4.1.jar |grep JndiLookup.class
2576 2015-10-08 17:50 org/apache/logging/log4j/core/lookup/JndiLookup.class

Im obigen Beispiel sind die JndiLookup.class Datei ist noch im Ordner log4j-core-2.4.1.jar jar-Datei.