Con respecto a la vulnerabilidad de ejecución remota de código Log4j JNDI que se ha identificado CVE-2021-44228 - (ver también referencias) - Me preguntaba si Log4j-v1.2 también se ve afectado, pero lo más cercano que obtuve de la revisión del código fuente es el JMS -Aplicador .
La pregunta es que, si bien las publicaciones en Internet indican que Log4j 1.2 también es vulnerable, no puedo encontrar el código fuente correspondiente.
¿Me estoy perdiendo algo que otros han identificado?
Log4j 1.2 parece tener una vulnerabilidad en la clase de servidor de socket , pero entiendo que debe habilitarse en primer lugar para que sea aplicable y, por lo tanto, no es una amenaza pasiva a diferencia de la vulnerabilidad de búsqueda JNDI que identificó. parece ser.
¿Tengo entendido que Log4j v1.2 no es vulnerable al error de ejecución jndi-remote-code correcto?
Esta publicación de blog de Cloudflare también indica el mismo punto que de AKX ... ¡que se introdujo a partir de Log4j 2!
Actualización n.º 1 : ahora está disponible una bifurcación de apache-log4j-1.2.x (ahora retirado) con correcciones de parches para algunas vulnerabilidades identificadas en la biblioteca anterior (del autor original de log4j). El sitio es https://reload4j.qos.ch/ . A partir del 21 de enero de 2022, se lanzó la versión 1.2.18.2. Las vulnerabilidades abordadas hasta la fecha incluyen las relacionadas con las vulnerabilidades JMSAppender , SocketServer y Chainsaw . Tenga en cuenta que simplemente estoy transmitiendo esta información. No he verificado las correcciones de mi parte. Consulte el enlace para obtener más detalles.
La función JNDI se agregó a Log4j 2.0-beta9 .
Log4j 1.x por lo tanto no tiene el código vulnerable.
Si bien no se ve afectado exactamente por el mismo problema de Log4Shell, elequipo de Apache Log4j recomienda eliminar JMSAppender y SocketServer , que tiene una vulnerabilidad en CVE-2019-17571 , de sus archivos JAR.
Puede usar el comando zip para eliminar las clases afectadas. Reemplace el nombre de archivo/versión con el suyo:
zip -d log4j-1.2.16.jar org/apache/log4j/net/JMSAppender.class zip -d log4j-1.2.16.jar org/apache/log4j/net/SocketServer.class Puede revisar los archivos en su zip usando less y grep , por ejemplo, less log4j-1.2.16.jar | grep JMSAppender
Dicho esto, Apache recomienda que actualice a la versión 2.x si es posible. Según su página de seguridad :
Tenga en cuenta que Log4j 1.x ha llegado al final de su vida útil y ya no es compatible. Las vulnerabilidades informadas después de agosto de 2015 contra Log4j 1.x no se verificaron y no se repararán. Los usuarios deben actualizar a Log4j 2 para obtener correcciones de seguridad.
Además de la respuesta de giraffesyo y en caso de que ayude a alguien, escribí este script Bash, que elimina las clases identificadas como vulnerabilidades (enlace aquí al hilo de desarrollo de Log4j ) y establece que los archivos de propiedades son de solo lectura, como se sugiere aquí en un hilo de Red Hat Bugzilla .
Nota 1: no verifica el uso de estas clases en las propiedades, es simplemente una forma de encontrar y eliminar, ¡úselo bajo su propio riesgo!
Nota 2: depende de la instalación de zip y unzip
#!/bin/bash DIR=$1 APPLY=$2 # Classes to be searched for/removed CLASSES="org/apache/log4j/net/SimpleSocketServer.class org/apache/log4j/net/SocketServer.class org/apache/log4j/net/JMSAppender.class" PROGNAME=`basename $0` PROGPATH=`echo $0 | sed -e 's,[\\/][^\\/][^\\/]*$,,'` usage () { echo >&2 Usage: ${PROGNAME} DIR [APPLY] echo >&2 Where DIR is the starting directory for find echo >&2 and APPLY = "Y" - to perform purification exit 1 } # Force upper case on Apply APPLY=$(echo "${APPLY}" | tr '[:lower:]' '[:upper:]') # Default Apply to N if [ "$APPLY" == "" ] ; then APPLY="N" fi # Check parameters if [ "$DIR" == "" ] ; then usage fi echo $APPLY | grep -q -i -e '^Y$' -e '^N$' || usage # Search for log4j jar files - for class file removal FILES=$(find $DIR -name *log4j*jar) for f in $FILES do echo "Checking Jar [$f]" for jf in $CLASSES do unzip -v $f | grep -e "$jf" if [ "$APPLY" = "Y" ] then echo "Deleting $jf from $f" zip -d $f $jf fi done done # Search for Log4j properties files - for read-only setting PFILES=$(find $DIR -name *log4j*properties) for f in $PFILES do echo "Checking permissions [$f]" if [ "$APPLY" = "Y" ] then echo "Changing permissons on $f" chmod 444 $f fi ls -l $f done