VxRail: Manager Remediate Apache Log4Shell beveiligingslek (CVE-2021-44228, CVE-2021-45046)

De Apache Software Foundation heeft informatie gepubliceerd over een kritiek probleem met betrekking tot het uitvoeren van externe code in de Apache Log4j Library dat bekend staat als Log4Shell volgens de GitHub Advisory Database (ook beschreven in CVE-2021-44228, CVE-2021-45046 en CVE-2021-4104). VxRail Manager is blootgesteld aan het probleem dat in het beveiligingslek wordt beschreven.
 

Zie de volgende artikelen voor meer informatie over deze CVE's:

• Beveiligingslekken in Apache Log4j
• CVE-2021-45046 (Log4j 2,15)
• CVE-2021-4104 (Log4j 1,2)

Er is nog een probleem ontdekt in het vorige script dat ertoe kan leiden dat een getroffen bestand wordt hersteld op VxRail Manager vanuit een systeemarchief. Dit probleem is ook aangepakt in deze release.

Als u eerdere scripts hebt gebruikt die bij dit artikel zijn geleverd, download dan het nieuwste script (1.1.2) en voer het uit op VxRail Manager om er zeker van te zijn dat u de volledige oplossing hebt.
 

Vereisten en toepassingsgebied

Dit bereik van wat wordt behandeld door de herstelstappen in dit artikel is:

• Dit artikel is van toepassing op VxRail Manager in VxRail 4.5.x-, 4.7.x- en 7.0.x-releases, samen met VxRail Manager in VCF 3.x- en 4.x-releases.
• Het script en de stappen voor herstel verhelpen alleen het beveiligingslek in de VxRail Manager appliance-VM.
• Andere componenten buiten VxRail Manager, zoals vCenter Server Appliance (vCSA), NSX, enzovoort, moeten afzonderlijk worden beperkt en zijn niet opgenomen in dit script.
• Het script lost ook geen applicaties of services op die worden uitgevoerd in VM's die mogelijk worden blootgesteld aan het beveiligingslek. Dell Technologies raadt alle klanten aan om bij hun applicatie- of softwareleveranciers te controleren of er services worden uitgevoerd in VM's om er zeker van te zijn dat ze niet worden beïnvloed.

Koppelingen naar getroffen VMware-producten en mogelijke tijdelijke oplossingen worden beschreven in het volgende VMware VMSA-artikel:

• VMware-beveiligingsadvies VMSA-2021-0028

VMware biedt een script voor het automatiseren van het herstel in de vCenter Server Appliance in het volgende artikel:

• Python-script voor het automatiseren van de tijdelijke oplossing van het beveiligingslek VMSA-2021-0028 op vCenter Server Appliance (87088)

Aan dit artikel is een bestand bijgevoegd fixlog4j-CVE-2021-44228-CVE-2021-45046-v-1-1-2.zip die alleen het script voor VxRail Manager bevat.
 

VxRail releases met fix inbegrepen

Dit probleem is opgelost in de volgende VxRail softwarereleases:

• VxRail pakketsoftware 7.0.320
• VxRail Appliance Software 4.7.541
• VxRail Appliance Software 4.5.471

Het wordt aanbevolen om te upgraden naar een VxRail softwarerelease die de oplossing bevat.
Het script wordt aanbevolen voor klanten die niet onmiddellijk kunnen upgraden.

• VxRail: vCenter upgraden naar 7.0 U3c of hoger mislukt vanwege mogelijk driverconflict

Aanvullende overwegingen voor verouderde patchscripts:

Als u eerder een updatescript hebt uitgevoerd (ouder dan fixlog4j-CVE-2021-44228-CVE-2021-45046-v-1-1-2.zip) op de VxRail Manager, houd rekening met het volgende:

• • Dat script maakt back-ups van originele jar-bestanden met een ".bak" extensie en bewaart ze in de oorspronkelijke bibliotheekmappen.

  • Deze .bak Bestanden kunnen problemen veroorzaken bij het opstarten van de service na een upgrade naar VxRail 8.0.380 of hoger, omdat ze per ongeluk samen met actieve bestanden in dezelfde map worden geladen.

Volg de onderstaande stappen om een verouderde .bak bestanden en zorgen voor een normale werking van het systeem:

1. Bestaande .bak bestanden controleren
   • find /mystic/connectors -name "log4j-core*.bak"
2. Als er .bak bestanden worden gevonden, verplaats ze dan naar een veilige locatie:
   • mkdir -p /tmp/log4jbak
   • find /mystic/connectors -name "log4j-core*.bak" -type f -exec mv {} /tmp/log4jbak/ \;
3. Check.bak bestanden die niet bestaan in /mystic/connectors en start de service opnieuw:

• • Scenario A - als u de LCM-upgrade nog NIET hebt uitgevoerd:
    • Ga verder met de LCM-upgrade. Alle services worden automatisch opnieuw gestart tijdens het upgradeproces.

• • Scenario B - als u de LCM-upgrade AL hebt voltooid en een fout met de VC-plug-in ervaart:
    • Start VxRail Manager opnieuw:
      • systemctl restart vmware-marvin
      • service runjars restart

Stappen voor probleemoplossing:

Voer de volgende stappen uit om de problemen op te lossen:

1. Download de fixlog4j-CVE-2021-44228-CVE-2021-45046-v-1-1-2.zip bestand dat aan dit artikel is gehecht.
2. Upload de .zip bestand naar VxRail Manager met behulp van mystic user over SCP (WinSCP is een voorbeeld van een SCP-client die kan worden gebruikt).
3. Meld u aan bij de VxRail Manager VM-console of SSH met behulp van de mystieke gebruiker. 
4. Wijzig de directory naar waar u de .zip Bestand bestand en pak het uit met de opdracht Uitpakken:

   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. Maak het script uitvoerbaar met behulp van het chmod Opdrachten

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

6. Meld u aan als de VxRail Manager-hoofdgebruiker met behulp van de su Opdrachten

   mystic@vxrm:~> su -
   Password:

7. Zorg ervoor dat u zich in dezelfde map bevindt als waar u het scriptpakket hebt uitgepakt:

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

8. Voer het script uit:

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

   Voorbeeld van scriptuitvoer:

   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

Wacht ten minste 10 minuten als u een van de onderstaande handmatige validatiestappen wilt uitvoeren.

Er zijn verschillende versies van de lib4j-core library, afhankelijk van de release van VxRail Manager.

Het script is ontworpen om VxRail Manager correct te herstellen, ongeacht de versie van lib4j-core die is opgenomen in die versie van VxRail Manager.

De bovenstaande uitvoer van het uitvoeren van het script kan verschillende bestanden laten zien die worden bijgewerkt, afhankelijk van de versie van lib4j-core die is opgenomen.
 

Koppelingen naar VMware-artikelen over tijdelijke oplossingen en oplossingen vindt u in VxRail: Informatie over Log4Shell (CVE-2021-44228/CVE-2021-45046/CVE-2021-4104) en VxRail-omgevingen
 

Validatiestappen

Om het probleem op te lossen, verwijdert het script de JndiLookup.class bestand uit de lib4j-core-* jar Bestanden.

Een jar-bestand is een Java-verpakkingsindeling voor het opnemen van meerdere klasse-, metadata- en andere Java-programma's in één bestand. Het is qua concept vergelijkbaar met een .zip bestand en is gebaseerd op de .zip Indeling: De scriptuitvoering valideert dat elk JAR-bestand met succes is bijgewerkt.

Als u een handmatige validatie wilt uitvoeren dat het script heeft gewerkt, kunt u controleren of het log4j-core-* jar bestanden op VxRail Manager bevatten nog steeds de getroffen JndiLookup.class Bestand: Als het heeft gewerkt, zou u geen uitvoer moeten zien voor de onderstaande opdrachten die de getroffen JndiLookup.class Bestand is niet langer aanwezig in het JAR-bestand.
 

 Validatie met geautomatiseerde opdracht 

De volgende opdracht kan worden uitgevoerd op VxRail Manager om te scannen op alle log4j-core-xxxx.jar bestanden op VxRail Manager en controleer of ze de getroffen bestanden bevatten JndiLookup.class Bestand:

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

Voorbeelduitvoer (bijgewerkt systeem):

/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

In het bovenstaande voorbeeld is de JndiLookup.class Bestand is niet aanwezig in JAR, dus het script werkte, en verificatie is geslaagd.

Hieronder vindt u een voorbeelduitvoer van een getroffen systeem die moet worden bijgewerkt:

/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

In het bovenstaande voorbeeld zijn de getroffen JndiLookup.class bestand nog steeds aanwezig is in de log4j-core-2.13.3.jar jar bestand.

Hieronder ziet u een voorbeelduitvoer van een systeem met een opgelost of bijgewerkt log4j-core bibliotheek waar het zien van de JndiLookup.class Bestand kan worden genegeerd:

/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

In het bovenstaande voorbeeld ziet u de JndiLookup.class bestand in de uitvoer, maar de oplossing voor het probleem is in log4j-core-2.17.1.jar.

 

Validatie met manuele controle van elk bestand

Om snel een log4j-core-xxxx.jar bestanden die aanwezig zijn op VxRail Manager, voert u de volgende opdracht uit (hiermee wordt de uitvoer ook opgemaakt in een bruikbare opdracht):

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

Voorbeeldresultaat:

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

Voer uit de bovenstaande voorbeelduitvoer elke opdracht handmatig uit om te zien of ze de getroffen JndiLookup.class Bestand:

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 #

In het bovenstaande voorbeeld is de JndiLookup.class Bestand is niet aanwezig in JAR, dus het script werkte, en verificatie is geslaagd.
 

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

In het bovenstaande voorbeeld zijn de getroffen JndiLookup.class bestand nog steeds aanwezig is in de log4j-core-2.4.1.jar jar bestand.