VxRail : Manager corrige les failles de sécurité Apache Log4Shell (CVE-2021-44228, CVE-2021-45046)
Résumé: Cet article décrit un script qui peut être exécuté sur VxRail Manager pour corriger la faille de sécurité Apache Log4Shell décrite dans CVE-2021-44228. CVE-2021-45046 et CVE-2021-4104 (article Dell DSN-2021-007, article VMware VMSA-2021-0028). ...
Instructions
Apache Software Foundation a publié des informations sur une faille de sécurité critique d’exécution du code à distance de la bibliothèque Apache Log4j, connue sous le nom de Log4Shell, conformément à la GitHub Advisory Database
Pour plus d’informations sur ces vulnérabilités CVE, consultez les articles suivants :
- Faille de sécurité Apache Log4j
- CVE-2021-45046
- CVE-2021-4104
Un problème supplémentaire a été découvert dans le script précédent, qui peut entraîner la restauration d’un fichier concerné sur VxRail Manager à partir d’une archive système. Ce problème a également été résolu dans cette version.
Si vous avez utilisé des scripts précédents fournis avec cet article, téléchargez le dernier script (1.1.2) et exécutez-le sur VxRail Manager pour être sûr de disposer du correctif complet.
Exigences et champ d’application
Le champ d’application des mesures correctives décrites dans cet article est le suivant :
- Cet article s’applique à VxRail Manager dans les versions VxRail 4.5.x, 4.7.x et 7.0.x, ainsi qu’à VxRail Manager dans les versions VCF 3.x et 4.x.
- Le script et les étapes de mesure corrective fournis corrigent la faille de sécurité dans la machine virtuelle de l’appliance VxRail Manager uniquement.
- Les autres composants en dehors de VxRail Manager, tels que vCenter Server Appliance (vCSA), NSX, etc., doivent être atténués séparément et ne sont pas inclus dans ce script.
- En outre, le script ne corrige aucune application ni aucun service exécuté dans des machines virtuelles susceptibles d’être exposées à la faille de sécurité. Dell Technologies recommande à tous les clients de vérifier auprès de leurs fournisseurs d’applications ou de logiciels les services s’exécutant sur des machines virtuelles pour s’assurer qu’ils ne sont pas affectés.
Les liens vers les produits VMware concernés et les solutions de contournement potentielles sont détaillés dans l’article VMware VMSA suivant :
VMware fournit un script permettant d’automatiser la mesure corrective dans vCenter Server Appliance dans l’article suivant :
Vous trouverez en pièce jointe à cet article un fichier fixlog4j-CVE-2021-44228-CVE-2021-45046-v-1-1-2.zip qui contient le script pour VxRail Manager uniquement.
Versions VxRail avec correctif inclus
Ce problème a été résolu dans les versions logicielles suivantes de VxRail :
- Logiciel du package VxRail 7.0.320
- Logiciel de l’appliance VxRail 4.7.541
- Logiciel de l’appliance VxRail 4.5.471
Il est recommandé d’effectuer une mise à niveau vers une version du logiciel VxRail qui inclut le correctif.
Le script est recommandé pour les clients qui ne sont pas en mesure d’effectuer une mise à niveau immédiatement.
Note: Si votre cluster VxRail 7.0.xxx est géré par un vCenter géré par le client, reportez-vous à l’article suivant pour connaître les considérations supplémentaires qui peuvent s’appliquer :
Considérations supplémentaires pour les scripts de correctifs hérités :
Si vous avez déjà exécuté un script de mise à jour antérieur (antérieur à fixlog4j-CVE-2021-44228-CVE-2021-45046-v-1-1-2.zip) sur VxRail Manager, tenez compte des points suivants :
-
- Ce script crée des copies de sauvegarde des fichiers jar d’origine avec une extension « .bak » et les conserve dans les répertoires de la bibliothèque d’origine.
-
Ces fichiers .bak peuvent entraîner des problèmes de démarrage du service après la mise à niveau vers VxRail 8.0.380 ou une version supérieure, car ils seront chargés par erreur avec les fichiers actifs du même répertoire.
Suivez les étapes ci-dessous pour déplacer les fichiers .bak existants et assurer le fonctionnement normal du système :
- Rechercher les fichiers .bak existants
find /mystic/connectors -name "log4j-core*.bak"
- Si .bak fichiers sont trouvés, déplacez-les vers un emplacement sûr :
mkdir -p /tmp/log4jbakfind /mystic/connectors -name "log4j-core*.bak" -type f -exec mv {} /tmp/log4jbak/ \;
- Check.bak fichiers qui n’existent pas dans
/mystic/connectors, puis redémarrez le service :
-
- Scénario A : si vous n’avez PAS encore effectué la mise à niveau LCM :
- Procédez à la mise à niveau LCM. Le processus de mise à niveau redémarre automatiquement tous les services.
- Scénario A : si vous n’avez PAS encore effectué la mise à niveau LCM :
-
- Scénario B : si vous avez DÉJÀ terminé la mise à niveau LCM et que vous rencontrez une défaillance du plugin VC :
- Redémarrez VxRail Manager :
systemctl restart vmware-marvinservice runjars restart
- Redémarrez VxRail Manager :
- Scénario B : si vous avez DÉJÀ terminé la mise à niveau LCM et que vous rencontrez une défaillance du plugin VC :
Étapes de mesure corrective
Pour corriger ces problèmes, procédez comme suit :
- Téléchargez le
fixlog4j-CVE-2021-44228-CVE-2021-45046-v-1-1-2.zipFichier joint à cet article. - Téléchargez le fichier .zip dans VxRail Manager à l’aide de l’utilisateur Mystic sur SCP (WinSCP est un exemple de client SCP pouvant être utilisé).
- Connectez-vous à la console de la machine virtuelle VxRail Manager ou à SSH à l’aide de l’utilisateur mystic.
- Accédez au répertoire dans lequel vous avez téléchargé le fichier .zip et extrayez-le à l’aide de la commande 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
- Rendez le script exécutable à l’aide de la commande chmod :
mystic@vxrm:~> chmod +x fixlog4j-CVE-2021-44228-CVE-2021-45046.sh
- Connectez-vous en tant qu’utilisateur root de VxRail Manager à l’aide de la commande su :
mystic@vxrm:~> su - Password:
- Assurez-vous que vous êtes dans le même répertoire que celui dans lequel vous avez extrait le package de script :
vxrm:~ # cd /home/mystic vxrm:/home/mystic #
- Exécutez le script :
vxrm:/home/mystic # ./fixlog4j-CVE-2021-44228-CVE-2021-45046.sh
Exemple de sortie de script :
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
Patientez au moins 10 minutes si vous prévoyez d’effectuer l’une des étapes de validation manuelle ci-dessous.
Il existe plusieurs versions différentes de la bibliothèque lib4j-core en fonction de la version de VxRail Manager.
Le script a été conçu pour corriger correctement VxRail Manager, quelle que soit la version de lib4j-core incluse avec cette version de VxRail Manager.
La sortie ci-dessus de l’exécution du script peut afficher différents fichiers en cours de mise à jour en fonction de la version de lib4j-core incluse.
Vous trouverez des liens vers des articles VMware couvrant les solutions de contournement de leurs produits et leurs correctifs dans VxRail : Informations sur les environnements Log4Shell (CVE-2021-44228/CVE-2021-45046/CVE-2021-4104) et VxRail
Étapes de validation
Afin de corriger le problème, le script supprime le fichier JndiLookup.class des fichiers jar lib4j-core-*.
Un fichier jar est un format de packaging Java pour inclure plusieurs classes, métadonnées et autres programmes Java dans un seul fichier. Il ressemble au concept du fichier .zip et repose sur le format .zip. L’exécution du script vérifie que chaque fichier jar a été mis à jour avec succès.
Pour effectuer une validation manuelle que le script a fonctionné, vous pouvez vérifier si le log4j-core-* Les fichiers jar présents sur VxRail Manager contiennent toujours le fichier JndiLookup.class concerné. Si cela a fonctionné, vous ne devriez voir aucune sortie vers les commandes ci-dessous qui confirme le JndiLookup.class Le fichier n’est plus présent dans le fichier jar.
JndiLookup.class le fichier est corrigé dans log4j-core-2.17.1.jar et les versions supérieures. Si vous tentez d’exécuter les étapes de validation sur ces fichiers jar, la commande JndiLookup.class Le fichier est présent, mais le problème n’est pas résolu. Il est prudent d’ignorer cela en voyant que JndiLookup.class fichier dans les versions corrigées de log4j-core.
Validation avec commande automatisée
La commande suivante peut être exécutée sur VxRail Manager pour analyser tous les log4j-core-xxxx.jar dans VxRail Manager et vérifiez s’ils contiennent les fichiers concernés. JndiLookup.class fichier :
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
Exemple de sortie (système mis à jour) :
/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
Dans l’exemple ci-dessus, l’attribut JndiLookup.class Le fichier n’est pas présent dans le fichier jar. Le script a donc fonctionné et la vérification a réussi.
Vous trouverez ci-dessous un exemple de sortie d’un système affecté qui doit être mis à jour :
/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
Dans l’exemple ci-dessus, le JndiLookup.class Le fichier est toujours présent dans le fichier log4j-core-2.13.3.jar fichier jar.
Vous trouverez ci-dessous un exemple de sortie d’un système qui dispose d’un système fixe ou mis à jour log4j-core bibliothèque où la vue de l' JndiLookup.class Le fichier peut être ignoré :
/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
Dans l’exemple ci-dessus, vous pouvez voir le JndiLookup.class dans la sortie, mais le correctif pour le problème se trouve dans log4j-core-2.17.1.jar.
Validation avec vérification manuelle de chaque fichier
Pour identifier rapidement tout log4j-core-xxxx.jar Dans les fichiers présents sur VxRail Manager, exécutez la commande suivante (ceci formate également le résultat en une commande utilisable) :
vxrm:/home/mystic # find / -name log4j-core*jar -print |grep -v log4jbak | awk '{print("unzip -l " $1 "|grep JndiLookup.class")}'
Exemple de résultat :
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
À partir de l’exemple de sortie ci-dessus, exécutez chaque commande manuellement pour voir si elles détectent le JndiLookup.class fichier :
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 #
Dans l’exemple ci-dessus, l’attribut JndiLookup.class Le fichier n’est pas présent dans le fichier jar. Le script a donc fonctionné et la vérification a réussi.
Exemple de sortie pour un fichier jar toujours affecté et contenant le fichier affecté
JndiLookup.class fichier :
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
Dans l’exemple ci-dessus, le JndiLookup.class Le fichier est toujours présent dans le fichier log4j-core-2.4.1.jar fichier jar.