VxRail: Manager corrige la vulnerabilidad de Apache Log4Shell (CVE-2021-44228 y CVE-2021-45046)
Resumen: En este artículo, se describe un script que se puede ejecutar en VxRail Manager para corregir la vulnerabilidad de Apache Log4Shell descrita en CVE-2021-44228, CVE-2021-45046 y CVE-2021-4104 (artículo de Dell DSN-2021-007, artículo de VMware VMSA-2021-0028). ...
Instrucciones
La Apache Software Foundation ha publicado información sobre un problema crítico de vulnerabilidad de ejecución remota de código de la biblioteca Apache Log4j que se conoce como Log4Shell según la base de datos de asesoría de GitHub (también se detalla en CVE-2021-44228
, CVE-2021-45046
y CVE-2021-4104
). VxRail Manager está expuesto al problema descrito en la vulnerabilidad.
Para obtener más información sobre estas CVE, consulte los siguientes artículos:
- Vulnerabilidades de seguridad de Apache Log4j
- CVE-2021-45046
(Log4j 2.15)
- CVE-2021-4104
(Log4j 1.2)
Se descubrió un problema adicional en el script anterior que puede provocar la restauración de un archivo afectado en VxRail Manager desde un archivo del sistema. Este problema también se ha abordado en esta versión.
Si utilizó alguno de los scripts anteriores que se proporcionaron con este artículo, descargue el script más reciente (1.1.2) y ejecútelo en VxRail Manager para asegurarse de tener la solución completa.
Requisitos y alcance
El alcance de lo abarcado en los pasos de corrección en este artículo es:
- Este artículo se aplica a VxRail Manager en las versiones 4.5.x, 4.7.x y 7.0.x de VxRail, junto con VxRail Manager en las versiones 3.x y 4.x de VCF.
- Los pasos de corrección y el script proporcionados corrigen la vulnerabilidad solo en la VM del dispositivo VxRail Manager.
- Otros componentes fuera de VxRail Manager, como vCenter Server Appliance (vCSA), NSX, etc., se deben mitigar por separado y no se incluyen en este script.
- Además, el script no corrige las aplicaciones ni los servicios en ejecución en las VM que pueden estar expuestas a la vulnerabilidad. Dell Technologies recomienda a todos los clientes que consulten con sus proveedores de aplicaciones o software los servicios que se ejecutan en las VM para asegurarse de que no se vean afectados.
Los enlaces a los productos de VMware afectados y las posibles soluciones alternativas se detallan en el siguiente artículo de VMSA de VMware:
VMware proporciona un script para automatizar la corrección en vCenter Server Appliance en el siguiente artículo:
Se adjunta a este artículo un archivo fixlog4j-CVE-2021-44228-CVE-2021-45046-v-1-1-2.zip que contiene el script solo para VxRail Manager.
Versiones de VxRail con corrección incluida
Este problema se resolvió en las siguientes versiones del software VxRail:
- Versión 7.0.320 del software del paquete de VxRail
- Versión 4.7.541 del software de VxRail Appliance
- Versión 4.5.471 del software de VxRail Appliance
Se recomienda actualizar a una versión del software de VxRail que incluya la corrección.
El script se recomienda para los clientes que no pueden realizar la actualización inmediatamente.
Nota: Si un vCenter administrado por el cliente administra el clúster de 7.0.xxx de VxRail, consulte el siguiente artículo para conocer consideraciones adicionales que pueden corresponder:
Consideraciones adicionales para scripts de parches heredados:
Si ejecutó anteriormente un script de actualización anterior (anterior a fixlog4j-CVE-2021-44228-CVE-2021-45046-v-1-1-2.zip) en VxRail Manager, tenga en cuenta lo siguiente:
-
- Ese script crea copias de seguridad de los archivos jar originales con una extensión ".bak" y los mantiene en los directorios de la biblioteca original.
-
Estos archivos .bak pueden causar problemas de inicio del servicio después de actualizar a VxRail 8.0.380 o superior, ya que se cargarán por error junto con los archivos activos en el mismo directorio.
Siga los pasos que se indican a continuación para reubicar los archivos de .bak heredados y garantizar el funcionamiento normal del sistema:
- Comprobar si existen archivos .bak
find /mystic/connectors -name "log4j-core*.bak"
- Si se encuentran .bak archivos, muévalos a una ubicación segura:
mkdir -p /tmp/log4jbakfind /mystic/connectors -name "log4j-core*.bak" -type f -exec mv {} /tmp/log4jbak/ \;
- Check.bak archivos que no existen en
/mystic/connectorsy, a continuación, reinicie el servicio:
-
- Situación A: si aún NO ha realizado la actualización de LCM:
- Continúe con la actualización de LCM. El proceso de actualización reiniciará automáticamente todos los servicios.
- Situación A: si aún NO ha realizado la actualización de LCM:
-
- Situación B: si YA completó la actualización de LCM y experimenta una falla del plug-in de VC:
- Reinicie VxRail Manager:
systemctl restart vmware-marvinservice runjars restart
- Reinicie VxRail Manager:
- Situación B: si YA completó la actualización de LCM y experimenta una falla del plug-in de VC:
Pasos para la corrección
Para corregir los problemas, realice los siguientes pasos:
- Descargue el archivo
fixlog4j-CVE-2021-44228-CVE-2021-45046-v-1-1-2.ziparchivo adjunto a este artículo. - Cargue el archivo.zip en VxRail Manager mediante un usuario oculto a través de SCP (WinSCP es un ejemplo de un cliente SCP que se puede utilizar).
- Inicie sesión en la consola de VM de VxRail Manager o en SSH con el usuario mystic.
- Cambie el directorio donde cargó el archivo de .zip y extráigalo con el comando de descomprimir:
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
- Haga que el script sea ejecutable mediante el comando chmod:
mystic@vxrm:~> chmod +x fixlog4j-CVE-2021-44228-CVE-2021-45046.sh
- Inicie sesión como usuario raíz de VxRail Manager con el comando su:
mystic@vxrm:~> su - Password:
- Asegúrese de que se encuentra en el mismo directorio en el que extrajo el paquete de script:
vxrm:~ # cd /home/mystic vxrm:/home/mystic #
- Ejecute el script:
vxrm:/home/mystic # ./fixlog4j-CVE-2021-44228-CVE-2021-45046.sh
Ejemplo de resultado 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
Espere al menos 10 minutos si planea realizar alguno de los siguientes pasos de validación manual.
Existen varias versiones diferentes de la biblioteca lib4j-core según la versión de VxRail Manager.
El script se diseñó para corregir correctamente VxRail Manager, independientemente de la versión de lib4j-core que se incluye con esa versión de VxRail Manager.
La salida anterior de la ejecución del script puede mostrar diferentes archivos que se actualizan según la versión de lib4j-core incluida.
Los enlaces a artículos de VMware que cubren soluciones alternativas para sus productos y correcciones se encuentran en VxRail: Información sobre los entornos de Log4Shell (CVE-2021-44228/CVE-2021-45046/CVE-2021-4104) y VxRail
Pasos para la validación
Para corregir el problema, el script elimina el archivo JndiLookup.class de los archivos jar lib4j-core-*.
Un archivo jar es un formato de paquete de Java para incluir múltiples clases, metadatos y otros programas de Java en un solo archivo. Es similar en concepto a un archivo .zip y se basa en este. La ejecución del script valida que cada archivo jar se haya actualizado correctamente.
Para realizar una validación manual de que el script ha funcionado, puede comprobar si el log4j-core-* Los archivos jar presentes en VxRail Manager aún contienen el archivo JndiLookup.class afectado. Si funcionó, no debería ver ningún resultado con los siguientes comandos, lo que confirma que se vio afectado JndiLookup.class El archivo ya no está presente en el archivo jar.
JndiLookup.class El archivo se corrigió en log4j-core-2.17.1.jar y versiones posteriores, por lo que intentar ejecutar los pasos de validación en estos archivos jar muestra el JndiLookup.class El archivo está presente, pero el problema no se corrigió. Es seguro ignorar ver eso JndiLookup.class archivo en versiones fijas de log4j-core.
Validación con comando automatizado
El siguiente comando se puede ejecutar en VxRail Manager para buscar todos los log4j-core-xxxx.jar archivos presentes en VxRail Manager y compruebe si contienen los archivos afectados JndiLookup.class archivo:
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
Salida de muestra (sistema actualizado):
/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
En el ejemplo anterior, el JndiLookup.class El archivo no está presente en JAR, por lo que el script funcionó y la verificación se realizó correctamente.
A continuación, se muestra un resultado de muestra de un sistema afectado que se debe actualizar:
/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
En el ejemplo anterior, el elemento JndiLookup.class El archivo todavía está presente en el archivo log4j-core-2.13.3.jar jar.
A continuación, se muestra un resultado de muestra de un sistema que tiene un sistema fijo o actualizado log4j-core biblioteca donde ver el JndiLookup.class El archivo se puede ignorar:
/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
En el ejemplo anterior, puede ver el JndiLookup.class archivo en la salida, pero la solución para el problema está en log4j-core-2.17.1.jar.
Validación con comprobación manual de cada archivo
Para identificar rápidamente cualquier log4j-core-xxxx.jar archivos presentes en VxRail Manager, ejecute el siguiente comando (esto también formatea la salida en un comando utilizable):
vxrm:/home/mystic # find / -name log4j-core*jar -print |grep -v log4jbak | awk '{print("unzip -l " $1 "|grep JndiLookup.class")}'
Resultado de muestra:
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
En el resultado de ejemplo anterior, ejecute cada comando manualmente para ver si detectan el resultado JndiLookup.class archivo:
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 #
En el ejemplo anterior, el método JndiLookup.class El archivo no está presente en JAR, por lo que el script funcionó y la verificación se realizó correctamente.
Un ejemplo de la salida de un archivo jar que aún se ve afectado y contiene el archivo afectado
JndiLookup.class archivo:
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
En el ejemplo anterior, el elemento JndiLookup.class El archivo todavía está presente en el archivo log4j-core-2.4.1.jar jar.