Log4j vulnerability - Is Log4j 1.2.17 vulnerable (was unable to find any JNDI code in source)?

Question

With regard to the Log4j JNDI remote code execution vulnerability that has been identified CVE-2021-44228 - (also see references) - I wondered if Log4j-v1.2 is also impacted, but the closest I got from source code review is the JMS-Appender.

The question is, while the posts on the Internet indicate that Log4j 1.2 is also vulnerable, I am not able to find the relevant source code for it.

Am I missing something that others have identified?

Log4j 1.2 appears to have a vulnerability in the socket-server class, but my understanding is that it needs to be enabled in the first place for it to be applicable and hence is not a passive threat unlike the JNDI-lookup vulnerability which the one identified appears to be.

Is my understanding - that Log4j v1.2 - is not vulnerable to the jndi-remote-code execution bug correct?

References

• Apache Log4j Security Vulnerabilities

• Zero-day in ubiquitous Log4j tool poses a grave threat to the Internet

• Worst Apache Log4j RCE Zero day Dropped on Internet

• ‘Log4Shell’ vulnerability poses critical threat to applications using ‘ubiquitous’ Java logging package Apache Log4j

This blog post from Cloudflare also indicates the same point as from AKX....that it was introduced from Log4j 2!

Update #1 - A fork of the (now-retired) apache-log4j-1.2.x with patch fixes for few vulnerabilities identified in the older library is now available (from the original log4j author). The site is https://reload4j.qos.ch/. As of 21-Jan-2022 version 1.2.18.2 has been released. Vulnerabilities addressed to date include those pertaining to JMSAppender, SocketServer and Chainsaw vulnerabilities. Note that I am simply relaying this information. Have not verified the fixes from my end. Please refer the link for additional details.

Ligurian

Does this answer your question? How to mitigate log4shell vulnerability in version 1.2 of log4j? – Pelson

This is tough because the guidance is still constantly evolving. I recommend checking out the specific page CISA set up for this: cisa.gov/uscert/apache-log4j-vulnerability-guidance – Milkfish

Answer 1

The JNDI feature was added into Log4j 2.0-beta9.

Log4j 1.x thus does not have the vulnerable code.

Intrust

Turns out log4j 1 could be vulnerable in certain configurations: github.com/apache/logging-log4j2/pull/… – Intrust

To add further confusion RHEL are now stating that some of their products have an implementation using 1.2 which are vulnerable. There will be a lot of research in this vulnerability over the up coming weeks (from good and bad actors) which could identify variations of the mechanism used. If at all possible at this point, it would be safest to upgrade to 2.15. RHEL CVE-2021-4104 – Unemployable

@Unemployable As alluded to in my comment, yes, log4j 1.x can be vulnerable if the JMS Appender is used (and it rarely is, apparently?) – Intrust

Let this be a lesson to us - don't upgrade to the latest version! – Arrogant

@Intrust can you describe how the JMS Appender must be used? What must be configured that it's vulnerable? What must be used in code to be vulnerable? I currently can't find examples to check if affected or not. I would like to be safe that our currently used 1.2.17 is not affected in the way we use it currently. – Obsolete

Maybe I can answer by myself... JMSAppender must be added as new appender in log4j configuration file (or via code), right? If that's not the case, there's no problem concerning this vulnerability. -- now there's a CVE: nvd.nist.gov/vuln/detail/CVE-2021-4104 – Obsolete

It's worth pointing out that, although Log4j 1.x is not vulnerable in the same way, it has multiple CVEs open at this point (nvd.nist.gov/vuln/detail/CVE-2021-4104, nvd.nist.gov/vuln/detail/CVE-2019-17571) and has been end-of-life since August 2015 (blogs.apache.org/foundation/entry/…). It might be worth considering, "If there's already multiple exploits, what else might be found?" for a library that's no longer receiving updates. – Milkfish

This accepted and most upvoted answer is misleading as it gives people a false sense of security, as BrentWritesCode's comment points out. – Ashtray

@AlbertHendriks - Had already mentioned socket-server (CVE-2019-17571) vulnerability in the original post. The answer also only has CVE-2021-44228 for context. So hopefully no one would have assumed downgrading would be without risks even if it was deemed to be a solution. Also the understanding is that JMSAppender (CVE-2021-4104) will be applicable only if its been enabled. – Ligurian

@RavindraHV Maybe it's a literal answer to your question, but a lot of people who are no experts in security come here to check if they should do something about their vulnerable project that's using Log4j 1.x – Ashtray

@AlbertHendriks - Have added a link to reload4j which as per understanding addresses atleast few of the vulnerabilities (the site has more details). So if they are still tracking, then at least the update should help. – Ligurian

Answer 2

While not affected by the exact same Log4Shell issue, the Apache Log4j team recommends to remove JMSAppender and SocketServer, which has a vulnerability in CVE-2019-17571, from your JAR files.

You can use the zip command to remove the affected classes. Replace the filename/version with yours:

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

You can look through through the files in your zip using less and grep, e.g. less log4j-1.2.16.jar | grep JMSAppender

That being said, Apache recommends that you upgrade to the 2.x version if possible. According to their security page:

Please note that Log4j 1.x has reached end of life and is no longer supported. Vulnerabilities reported after August 2015 against Log4j 1.x were not checked and will not be fixed. Users should upgrade to Log4j 2 to obtain security fixes.

Crider

Just to add a reminder - log4j jar files will still reside in deployed war files and in developer maven respositories. So any rebuild of the application and redeploy using these will reintroduce these classes. – Throat

Answer 3

In addition to giraffesyo's answer and in case it helps anyone - I wrote this Bash script - which removes classes identified as vulnerabilities (link here to Log4j dev thread) and sets properties files are read-only - as suggested here on a Red Hat Bugzilla thread.

Note 1 - it does not check for any usage of these classes in properties it is purely a way to find and remove - use at own risk!

Note 2 - it depends on zip and unzip being installed

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

Throat