Vulnerabilidad de Log4j: ¿es vulnerable Log4j 1.2.17 (no se pudo encontrar ningún código JNDI en la fuente)?

Con respecto a la Log4j JNDI vulnerabilidad de ejecución remota de código que ha sido identificada 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-Appender.

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 el servidor de socket class, pero tengo entendido 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 parece ser la identificada.

¿Tengo entendido que Log4j v1.2 no es vulnerable al error de ejecución jndi-remote-code correcto?

Referencias

• Vulnerabilidades de seguridad de Apache Log4j

• El día cero en la omnipresente herramienta Log4j representa una grave amenaza para Internet

• El peor Apache Log4j RCE Zero Day lanzado en Internet

• La vulnerabilidad ‘Log4Shell’ representa una amenaza crítica para las aplicaciones que utilizan el paquete de registro de Java ‘ubicuo’ Apache Log4j

Este publicación de blog de Cloudflare también indica el mismo punto que en AKX… ¡que se introdujo en Log4j 2!

Actualización #1 – Ya 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 aquellas relacionadas con JMSAppender, servidor de sockets y motosierra vulnerabilidades. 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, el Equipo Apache Log4j recomienda eliminar JMSAppender y SocketServerque tiene una vulnerabilidad en CVE-2019-17571de sus archivos JAR.

Puedes usar el zip comando 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 menos y grepp.ej less log4j-1.2.16.jar | grep JMSAppender

Dicho esto, Apache recomienda que actualice a la versión 2.x si es posible. De acuerdo a su pagina 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í para el 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 zip y unzip siendo instalada

#!/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