Recientemente se descubrió una vulnerabilidad crítica de log4j .
Quiero actualizar log4j como lo usa mi instancia actual de Solr, así que verifiqué aquí . Sin embargo, no veo un archivo log4j.properties en la carpeta "/server/resources/". Todo lo que veo allí es:
Ninguno de estos archivos contiene una versión. Entonces, para actualizar, ¿es seguro descargar la última versión de log4j y sobrescribir los archivos jar existentes en la carpeta "\solr-8.10.1\server\lib\ext", o cuáles son los pasos recomendados para actualizar?
Si está ejecutando Solr como una ventana acoplable, lo que puede hacer es montar la misma versión de log4j-core que usa en la imagen de Solr, afuera después de eliminar JndiLookup.class del contenedor.
Déjame ir a través de los pasos que he usado.
Encuentre la versión de log4j-core que está usando la imagen de Solr. Puede hacerlo ejecutando el siguiente comando en su máquina host en ejecución Solr o después de ingresar a su contenedor Solr
buscar / -nombre "log4j-core-*.jar"
Allí obtendrás dos caminos. De acuerdo con la página de noticias de seguridad de Solr , podemos ignorar la ruta prometheus-exporter Prometheus. Lo que quedará es server/lib/ext/ path
Copie ese archivo .jar en particular o descargue la misma versión de Internet. He probado esto con log4j-core-2.11.2.jar
Copie ese archivo jar en su contenedor Solr que ejecuta la máquina host y verifique su estado de vulnerabilidad usando este detector log4j .
No es nada complicado, verificar esa vulnerabilidad usando la herramienta mencionada anteriormente. Lo que debe hacer es descargar ese archivo log4j-detector-2021.12.16.jar en una ubicación accesible y ejecutar el comando contra su archivo jar log4j-core.
java -jar log4j-detector-2021.12.16.jar 8.4.1-ext > hits_8.4.1_ext.txt
Luego obtendrá una salida como la siguiente diciendo que es vulnerable.
/ext/log4j-core-2.11.2.jar contiene Log4J-2.x >= 2.10.0 VULNERABLE :-(
Ahora eliminemos JndiLookup.class de ese archivo jar log4j-core
zip -q -d 8.4.1-ext/ext/log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Luego, verifique la vulnerabilidad nuevamente contra el mismo archivo jar de log4j-core y podrá ver algo como a continuación.
/ext/log4j-core-2.11.2.jar contiene Log4J-2.x <= 2.0-beta8 POTENCIALMENTE_SEGURO :-| (¿o ya eliminó JndiLookup.class?)
Eso significa que la eliminación de JndiLookup.class se ha realizado correctamente.
Montemos ese archivo jar log4j-core usando docker-compose.yaml
volúmenes:
- ./log4j-core-2.11.2.jar:/opt/solr-8.4.1/server/lib/ext/log4j-core-2.11.2.jar
Ahora, reinicie su contenedor acoplable Solr.
Mi preferencia personal es actualizar la propiedad con SOLR_OPTS con variables de entorno, ya que es agradable y limpio.
Mitigación: Cualquiera de los siguientes es suficiente para prevenir esta vulnerabilidad para los servidores Solr:
Actualice a Solr 8.11.1 o superior (cuando esté disponible), que incluirá una versión actualizada (>= 2.17.0) de la dependencia Log4J.
Si está utilizando la imagen de docker oficial de Solr, ya se ha mitigado en todas las versiones enumeradas como admitidas en Docker Hub: https://hub.docker.com/_/solr . Es posible que deba volver a extraer la imagen.
Actualice manualmente la versión de Log4J en su classpath de tiempo de ejecución y reinicie su aplicación Solr.
(Linux/MacOS) Edite su archivo solr.in.sh para incluir: SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true"
(Windows) Edite su archivo solr.in.cmd para incluir: establecer SOLR_OPTS=%SOLR_OPTS% -Dlog4j2.formatMsgNoLookups=true
Siga cualquiera de las otras mitigaciones enumeradas en https://logging.apache.org/log4j/2.x/security.html
Haciendo referencia a: https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228
En mi caso, los siguientes archivos jar se vieron afectados y reemplazados por el paquete más reciente directamente desde Apache . Use algo como el detector log4j para identificar los frascos afectados.
El enlace al que está apuntando es para una versión anterior de Solr (6.6 en lugar de 8.10.1). La versión correcta es https://solr.apache.org/guide/8_10/configuring-logging.html donde menciona el uso de log4j 2.
El archivo log4j2.xml (e incluso `log4j.properties para el caso) configura el registro en sí, no la versión de log4j. Entonces actualizar ese archivo es irrelevante.
Esto es lo que recomienda la página del proyecto :
2021-12-10, Apache Solr afectado por Apache Log4J CVE-2021-44228
...
Descripción: las versiones de Apache Solr anteriores a la 8.11.1 usaban una versión integrada de la biblioteca Apache Log4J vulnerable a RCE. Para ver el impacto completo y detalles adicionales, consulte la página de seguridad de Log4J.
...
Mitigación: Cualquiera de los siguientes es suficiente para prevenir esta vulnerabilidad para los servidores Solr:
- Actualice a Solr 8.11.1 o superior (cuando esté disponible), que incluirá una versión actualizada de la dependencia log4j2.
- Actualice manualmente la versión de log4j2 en su classpath de tiempo de ejecución y reinicie su aplicación Solr.
- (Linux/MacOS) Edite su archivo solr.in.sh para incluir: SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true"
- (Windows) Edite su archivo solr.in.cmd para incluir: establecer SOLR_OPTS=%SOLR_OPTS% -Dlog4j2.formatMsgNoLookups=true
- Siga cualquiera de las otras mitigaciones enumeradas en https://logging.apache.org/log4j/2.x/security.html
Lo que está proponiendo (sobrescribir los archivos jar existentes en la carpeta "\solr-8.10.1\server\lib\ext") parece ser el segundo enfoque, por lo que probablemente debería funcionar bien. Solo asegúrese de que este sea el lugar correcto que contiene la dependencia log4j.
Actualicé todos mis archivos jar log4j de 2.11 a 2.15 en mi carpeta /opt/solr-7.4.0/server/lib/ext y no veo ningún problema. Su enfoque parece funcionar.
Reemplace todos los frascos con su correspondiente versión 2.15 en lib/ext y reinicie solr. Parece que funciona.
Para una versión 8.6.4 de Solr, realicé una actualización a log4j2 2.16 simplemente intercambiando los 5 archivos log4j*.jar en "Solr\server\lib\ext". Además también tuve que actualizar slf4j-api.jar a la versión 1.7.24. Esto parece funcionar fuera de la caja.
descargar enlaces:
Con el nuevo CVE SOLR_OPTS no es suficiente. Actualizar a 2.17 parece la mejor opción. Esto es lo que funcionó para nosotros.
sudo find / -name "*log4j*" cd /app/solr/solr-7.7.0/server/lib/ext/ sudo curl https://dlcdn.apache.org/logging/log4j/2.17.0/apache-log4j-2.17.0-bin.zip --output apache-log4j-2.17.0-bin.zip sudo unzip apache-log4j-2.17.0-bin.zip sudo rm log4j-*-2.11* sudo cp apache-log4j-2.17.0-bin/{log4j-1.2-api-2.17.0.jar,log4j-api-2.17.0.jar,log4j-core-2.17.0.jar,log4j-slf4j-impl-2.17.0.jar} ./ sudo chown solr:solrgrp * sudo chmod 755 * sudo service solr restart cd /app/solr/solr-7.7.0/contrib/prometheus-exporter/lib/ sudo rm log4j-*-2.11* sudo cp /app/solr/solr-7.7.0/server/lib/ext/apache-log4j-2.17.0-bin/{log4j-api-2.17.0.jar,log4j-core-2.17.0.jar,log4j-slf4j-impl-2.17.0.jar} ./ sudo chown solr:solrgrp * sudo chmod 755 * sudo service solr restart