Log4j-Schwachstelle – Ist Log4j 1.2.17 angreifbar (konnte keinen JNDI-Code im Quellcode finden)?

In Bezug auf die Log4j JNDI Schwachstelle bezüglich Remotecodeausführung, die identifiziert wurde CVE-2021-44228 – (siehe auch Referenzen) – Ich habe mich gefragt, ob Log4j-v1.2 ist ebenfalls betroffen, aber am nächsten kommt mir die Überprüfung des Quellcodes JMS-Appender.

Die Frage ist, obwohl die Beiträge im Internet darauf hindeuten, dass Log4j 1.2 ebenfalls angreifbar ist, kann ich den entsprechenden Quellcode dafür nicht finden.

Übersehe ich etwas, das andere identifiziert haben?

Log4j 1.2 scheint eine Schwachstelle in der Socket-Server Klasse, aber ich verstehe, dass es überhaupt aktiviert werden muss, damit es anwendbar ist, und daher keine passive Bedrohung ist, im Gegensatz zu der JNDI-Lookup-Schwachstelle, die die identifizierte zu sein scheint.

Ist mein Verständnis – dass Log4j v1.2 – nicht anfällig für den Ausführungsfehler von jndi-remote-code ist, richtig?

Verweise

• Apache Log4j-Sicherheitslücken

• Zero-Day im allgegenwärtigen Log4j-Tool stellt eine ernsthafte Bedrohung für das Internet dar

• Der schlechteste Apache Log4j RCE Zero Day wurde im Internet gelöscht

• Die „Log4Shell“-Schwachstelle stellt eine kritische Bedrohung für Anwendungen dar, die das „allgegenwärtige“ Java-Protokollierungspaket Apache Log4j verwenden

Das Blogbeitrag von Cloudflare zeigt auch den gleichen Punkt wie von AKX an …. dass es von Log4j 2 eingeführt wurde!

Update Nr. 1 – Ein Fork des (inzwischen ausgemusterten) apache-log4j-1.2.x mit Patch-Fixes für einige Schwachstellen, die in der älteren Bibliothek identifiziert wurden, ist jetzt verfügbar (vom ursprünglichen log4j-Autor). Die Seite ist https://reload4j.qos.ch/. Am 21.01.2022 wurde die Version 1.2.18.2 veröffentlicht. Zu den bisher behobenen Schwachstellen gehören die in Bezug auf JMSAppender, SocketServer Und Kettensäge Schwachstellen. Beachten Sie, dass ich diese Informationen lediglich weitergebe. Habe die Korrekturen von meiner Seite nicht überprüft. Bitte beachten Sie den Link für weitere Details.

Die JNDI-Funktion wurde in Log4j 2.0-beta9 hinzugefügt.

Log4j 1.x hat also nicht den verwundbaren Code.

Obwohl nicht von genau demselben Log4Shell-Problem betroffen, ist die Apache Log4j-Team empfiehlt zu entfernen JMSAppender Und SocketServerdas eine Schwachstelle in hat CVE-2019-17571aus Ihren JAR-Dateien.

Du kannst den … benutzen zip Befehl zum Entfernen der betroffenen Klassen. Ersetzen Sie den Dateinamen/die Version durch Ihren:

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

Sie können die Dateien in Ihrer ZIP-Datei mit durchsuchen weniger Und grepz.B less log4j-1.2.16.jar | grep JMSAppender

Abgesehen davon empfiehlt Apache, dass Sie nach Möglichkeit auf die Version 2.x aktualisieren. Entsprechend ihre Sicherheitsseite:

Bitte beachten Sie, dass Log4j 1.x das Lebensende erreicht hat und nicht mehr unterstützt wird. Schwachstellen, die nach August 2015 gegen Log4j 1.x gemeldet wurden, wurden nicht überprüft und werden nicht behoben. Benutzer sollten auf Log4j 2 aktualisieren, um Sicherheitsfixes zu erhalten.

Zusätzlich zu giraffesyos Antwort und falls es jemandem hilft – ich habe dieses Bash-Skript geschrieben – das Klassen entfernt, die als Schwachstellen identifiziert wurden (link hier zum Log4j-Entwicklungsthread) und setzt Eigenschaftendateien sind schreibgeschützt – wie vorgeschlagen hier in einem Red Hat Bugzilla-Thread.

Hinweis 1 – Es wird nicht auf die Verwendung dieser Klassen in Eigenschaften geprüft, es ist lediglich eine Möglichkeit, sie zu finden und zu entfernen – Verwendung auf eigene Gefahr!

Hinweis 2 – es kommt darauf an zip Und unzip wird installiert

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