VxRail: VxRail Manager kan lösa säkerhetsproblem med Apache Log4Shell (CVE-2021-44228, CVE-2021-45046 och CVE-2021-4104)

Apache Software Foundation har publicerat information om ett kritiskt säkerhetsproblem med fjärrkörning av kod i Apache Log4j-biblioteket som kallas Log4Shell enligt GitHub Advisory Database (beskrivs även i CVE-2021-44228, CVE-2021-45046 och CVE-2021-4104). VxRail Manager utsätts för problemet som beskrivs i säkerhetsproblemet.

Observera: Två ytterligare CVE:er, CVE-2021-45046 och CVE-2021-4104, rapporteras som indikerar att den ursprungliga rekommendationen för att åtgärda problemet som beskrivs i CVE-2021-44228 (Log4j 2.x) inte är en fullständig lösning.

Mer information om dessa CVE:er finns i följande artiklar:

• Säkerhetsproblem med Apache Log4j
• CVE-2021-45046 (Log4j 2.15)
• CVE-2021-4104 (Log4j 1.2)

Obs! Skriptet i den här artikeln har uppdaterats till version 1.1.2 som innehåller de åtgärder som rekommenderas för alla tre CVE:er, CVE-2021-44228, CVE-2021-45046 och CVE-2021-4104.

Ett ytterligare problem upptäcktes i föregående skript, vilket kan leda till att en påverkad fil återställs i VxRail Manager från ett systemarkiv. Det här problemet har också åtgärdats i den här versionen.

Om du använde tidigare skript som medföljde den här artikeln hämtar du det senaste skriptet (1.1.2) och kör det på VxRail Manager för att säkerställa att du har den fullständiga korrigeringen.
 

Krav och omfattning

Det här omfattar följande åtgärder i den här artikeln:

• Den här artikeln gäller VxRail Manager i versionerna VxRail 4.5.x, 4.7.x och 7.0.x tillsammans med VxRail Manager i version 3.x och 4.x av VCF.
• Skript- och åtgärdsstegen som åtgärdar säkerhetsproblemet endast i VxRail Manager Appliance VM.
• Andra komponenter utanför VxRail Manager, till exempel vCenter Server Appliance (vCSA), NSX osv. måste mildras separat och finns inte i det här skriptet.
• Skriptet åtgärdar inte heller program eller tjänster som körs i virtuella datorer som kan vara exponerade för säkerhetsproblemet. Dell EMC rekommenderar att alla kunder kontrollerar med sina program- eller programvaruleverantörer om tjänster som körs i virtuella datorer för att säkerställa att de inte påverkas.

Länkar till påverkade VMware-produkter och potentiella lösningar beskrivs i följande VMware VMSA-artikel:

• VMware säkerhetsrekommendation VMSA-2021-0028

VMware tillhandahåller ett skript för att automatisera reparationen i vCenter Server Appliance i följande artikel:

• Python-skript för att automatisera de tillfälliga stegen i VMSA-2021-0028-säkerhetsproblem på vCenter Server Appliance (87088)

Den här artikeln innehåller filen fixlog4j-CVE-2021-44228-CVE-2021-45046-v-1-1-2.zip som endast innehåller skriptet för VxRail Manager.
 

VxRail-versioner med korrigering ingår

Problemet har lösts i följande VxRail-programvaruversioner:

• VxRail-paketprogramvara 7.0.320
• VxRail Appliance Software 4.7.541
• VxRail Appliance Software 4.5.471

Vi rekommenderar att du uppgraderar till en VxRail-programvaruversion med korrigeringen.
Skriptet rekommenderas för kunder som inte kan uppgradera omedelbart.

Observera: Om VxRail 7.0.xxx-klustret hanteras av en kundhanterad vCenter läser du följande artikel för ytterligare överväganden som kan gälla:

• Dell EMC VxRail: Uppgradering av externt vCenter till 7.0 U3c eller senare misslyckas vid förkontroll på grund av att värdar inte uppgraderas först.

 

Åtgärdssteg

Utför följande åtgärder mot problemet:

1. Ladda ner filen fixlog4j-CVE-2021-44228-CVE-2021-45046-v-1-1-2.zip som är bifogad den här artikeln.
2. Ladda upp .zip-filen till VxRail Manager med hjälp av en mystik användare via SCP (WinSCP är ett exempel på en SCP-klient som kan användas).
3. Logga in på VxRail Manager VM-konsolen eller SSH med hjälp av den mystikbaserade användaren. 
4. Ändra katalogen till den plats där du laddade upp .zip-filen och extrahera den med kommandot unzip:
   mystic@vxrm:~> packar upp fixlog4j-CVE-2021-44228-CVE-2021-45046-v-1-1-2.zip
   Arkiv:  fixlog4j-CVE-2021-44228-CVE-2021-45046-v-1-1-2.zip
   uppflätning: fixlog4j-CVE-2021-44228-CVE-2021-45046.sh
5. Gör skriptet körbart med chmod-kommandot :
   mystic@vxrm:~> chmod +x fixlog4j-CVE-2021-44228-CVE-2021-45046.sh
6. Logga in som VxRail Manager root-användare med hjälp av su-kommandot:
   mystic@vxrm:~> su –
   Lösenord:
7. Se till att du befinner dig i samma katalog där du packar upp skriptpaketet:
   vxrm:~ # cd /home/mystic
   vxrm:/home/mystic #
8. Kör skriptet:
   vxrm:/home/mystic # ./fixlog4j-CVE-2021-44228-CVE-2021-45046.sh

   Exempelskriptutdata:
   Stoppa TJÄNSTEN WIPE och runjars innan du korrigerar systemet
   
   /mystic/connectors/eservice/lib/log4j-core-2.13.0.jar påverkas av CVE-2021-44228 och CVE-2021-45046. Du måste använda korrigeringsfilskorrigering
   /mystic/connectors/eservice/lib/log4j-core-2.2.13.0.jar
   Har korrigerat /mystic/connectors/eservice/lib/log4j-core-2.13.0.jar
   
   /mystic/connectors/cluster/lib/log4j-core-2.13.0.jar påverkas av CVE-2021-44228 och CVE-2021-45046, måste tillämpa korrigeringsfilen
   patching /mystic/connectors/cluster/lib/log4j-core-2.13.0.jar
   Successfully patched /mystic/connectors/cluster/lib/log4j-core-2.13.0.jar
   
   För att säkerställa att det inte förekommer något beteende för ny inläsning, vi måste även packa .war-filen.
   det ser ut som /usr/lib/vmware-roth/rothd/webapps/ROOT.war innehåller det felaktiga log4j-core-biblioteket WEB-INF/lib/log4j-core-2.13.0.jar
   Archive:  /usr/lib/vmware-router/rothd/webapps/ROOT.war
   inflating: WEB-INF/lib/log4j-core-2.13.0.jar
   Patching WEB-INF/lib/log4j-core-2.13.0.jar i /usr/lib/vmware-router/routerd/webapps/ROOT.war
   Repack /usr/lib/vmware-roth/identified/webapps/ROOT.war
   updating: WEB-INF/lib/log4j-core-2.13.0.jar (de tömd 11 %)
   Rensa ROOT-mappen ...
   
   Använd alltid en omstart av REBOOT och runjars-tjänsterna
   för att starta om EN ARD- OCH ENR-omstart
   
   av RUNJARS
   som de ska

Obs! Det kan ta allt från 5–10 minuter innan alla filer har åtgärdats och VxRail Manager-tjänsterna kan starta.

Vänta minst 10 minuter om du planerar att utföra något av de manuella valideringsstegen nedan.

Det finns flera olika versioner av lib4j-core-biblioteket beroende på versionen av VxRail Manager.

Skriptet har utformats för att åtgärda VxRail Manager på rätt sätt oavsett vilken version av lib4j-core som ingår i den versionen av VxRail Manager.

Ovanstående utdata från körning av skriptet kan visa olika filer som uppdateras beroende på vilken version av lib4j-core som ingår.

Observera: Om du utför en VxRail-uppgradering till en annan version av VxRail som inte innehåller en korrigering måste skriptet köras en andra gång för att åtgärda problemet på nytt.
 

 OBS! För den fullständiga åtgärden för VxRail krävs att både vCenter Server Appliance-lösningen (vCSA) från VMware och reparationen i VxRail Manager som utförs av det här skriptet implementeras.

Länkar till VMware-artiklar om lösningar för deras produkter och korrigeringar finns i VxRail: Information om Log4Shell- (CVE-2021-44228) och VxRail-miljöer.
 

Valideringssteg

För att åtgärda problemet tar skriptet bort filen JndiLookup.class från filerna lib4j-core-* jar.

En jar-fil är ett Java-förpackningsformat för att inkludera flera klasser, metadata och andra Java-program i en enda fil. Det liknar en .zip-fil i konceptet och är baserat på .zip-formatet. Skriptkörningen bekräftar att alla jar-filer har uppdaterats.

Om du vill utföra en manuell validering som skriptet har fungerat kan du kontrollera om log4j-core-* jar-filerna i VxRail Manager fortfarande innehåller den påverkade JndiLookup.class-filen . Om det har fungerat bör du inte se några utdata till nedanstående kommandon som bekräftar att den påverkade JndiLookup.class-filen inte längre finns i jar-filen.
 

Validering med automatiserat kommando

Följande kommando kan köras i VxRail Manager för att söka efter alla log4j-core-xxxx.jar-filer i VxRail Manager och kontrollera om de innehåller den påverkade JndiLookup.class-filen :

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

output (uppdaterat system):
/mystic/connectors/eservice/lib/log4j-core-2.13.0.jar
/mystic/connectors/cluster/lib/log4j-core-2.13.0.jar
/usr/lib/vmware-ces/billd/webapps/ROOT/WEB-INF/lib/log4j-core-2.13.0.jarI

exemplet ovan fanns inte JndiLookup.class-filen i jar, vilket betyder att skriptet fungerade, och verifieringen lyckas.

Nedan visas exempel på utdata från ett påverkat system som måste uppdateras:
/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-alias/ed/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

. I exemplet ovan finns den påverkade filen JndiLookup.class fortfarande i filen log4j-core-2.13.3.jar.
 

Validering med manuell kontroll av varje fil

Så här identifierar du snabbt alla log4j-core-xxxx.jar-filer i VxRail Manager kör följande kommando (detta formaterar också utdata till ett användbart kommando):
vxrm:/home/mystic # find / -name log4j-core*jar -print |grep -v log4jbak | awk '{print("unzip -l " $1 "|grep JndiLookup.class")}'

Exempelutdata:
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.classunzip
-l /usr/lib/vmware-jpd/webapps/ROOT/WEB-INF/lib/log4j-core-2.13.0.jar|grep JndiLookup.classFrom

exemplet ovan, kör varje kommando manuellt för att se om de upptäcker den påverkade JndiLookup.class-filen:
vxrm:/home/mystic # unzip -l /mystic/connectors/eservice/lib/log4j-core-2.13.0.jar|grep JndiLookup.classvxrm
:/home/mystic #

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

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

I exemplet ovan finns inte filen JndiLookup.class i jar, så skriptet fungerade, och verifieringen lyckas.

Observera: Jar-filnamnen från exemplet ovan kan variera beroende på vilken version av VxRail Manager du har. Använd exempelutdata som du får från ovanstående sökkommando . 

Ett exempel på utdata för en jar-fil som fortfarande påverkas och innehåller den påverkade JndiLookup.class-filen:vxrm:/home/mystic # unzip -l /mystic/connectors/cluster/lib/log4j-core-2.4.1.jar |grep JndiLookup.class2576
2015-10-08 17:50 org/apache/logging/log4j/core/lookup/JndiLookup.classI

exemplet ovan finns den påverkade JndiLookup.class-filen fortfarande kvar i filen log4j-core-2.4.1.jar jar.

 

 OBS! En annan påminnelse om att fullständig risk för VxRail kräver att både vCenter Server Appliance-lösningen (vCSA) från VMware och reparationen på VxRail Manager som utförs av det här skriptet ska implementeras.