How to mitigate log4shell vulnerability in version 1.2 of log4j? [duplicate]

Question

I've got a very old version of Solr and I've been trying to see if it is affected by the Log4Shell vulnerability that everybody is freaking out about (CVE-2021-44228).

The CVE only seems to apply to later versions, but a colleague doesn't buy it, so I'm trying to figure out the truth.

Answer 1

I'm about 95% sure this is fine for older versions of Log4j. Three reasons:

1. I'm on version 1.2. I found the Log4j JAR file on my system, unzipped it, and looked for anything mentioning JNDI:

   find / -iname '*log4j*'
   unzip /etc/opt/jetty/lib/ext/log4j-1.2.17.jar | grep -i jndi
   

   That brought back nothing, so I feel pretty good there. The CVE says that you'd normally find something by looking in the JAR file. It suggests you do:

    zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
   

   That wouldn't do anything for me.

2. I dug through the changelog for Log4j. It says for version 2.0-beta9:

   Add JNDILookup plugin. Fixes LOG4J2-313. Thanks to Woonsan Ko.

   So I think it's safe to say that JNDI didn't exist in Log4j before then. The Jira ticket that added it is here.

3. I checked the old manual for version 1.2 and compared it to the latest version. In the latest, there's a section for "Lookups" that explains how JNDI works. In version 1.2, that section just isn't there.

I think it's...fine?

Answer 2

Ralph Goers (Apache Log4J maintainer) said:

There are two aspects to this vulnerability.

1. Log4j 2’s lookup mechanism (property resolver) was being performed on the message text being logged. This meant that if applications are logging user input (almost everyone does) a user could cause the Lookup mechanism to be invoked.
2. Log4j 2 supports JNDI in various places, including as a lookup. JNDI itself is horribly insecure. The combined effect of these is what makes it a critical severity issue for Log4j 2. Log4j 1, as well as Logback, both have components that use JNDI and neither do anything to limit the JNDI vulnerabilities. In the case of Log4j 1 it is the JMS Appender. The exposure is smaller but it is still there. If someone can gain access to the logging configuration they could conceivably cause bad things to happen.