How can I mitigate the 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.

Lucent

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?

Lucent

I dont find any log4j files on any of my machines. find / -iname 'log4j' comes up with nothing - am I ok? – Delk

Though keep in mind that Log4j 1 reached end of life in 2015. You should switch to a different logging framework either way, whether that is Log4j 2, Logback, or something else. – Tirzah

log4j 1.x seems to be vulnerable, if JMSAppender is used. See github.com/apache/logging-log4j2/pull/… – Vaunt

"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. -q is quiet operation for zip, so you probably wont see anything even if it did find something. – Gasiform

@ScottyJ, yes, I wouldn't see anything b/c of -q, but the command before would have shown something (b/c it doesn't use -q). – Lucent

@Maksim, reading those comments, it seems like the vulns in log4j 1.x are much less than those presented here. They seem to fall in the, "You should upgrade, but your house isn't on fire" territory. This, for example, indicates that the 1.x vuln depends on the using a particular configuration that's probably not that common. I'm not in my wheelhouse with Java though, so correct me if I'm missing something, please. – Lucent

@mlissner: I would rather just say : do not configure any usage of JmsAppender in 1.x – Vaunt

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.

So the conclusion is that Log4J 1.x is secure and not impacted by the Log4Shell unless you use JMS appender. In that case you have to analyze what you do in the appender.

Coppola

We dont use the JMS appender in 1.2, will it still be accessible the logging configuration ? – Heelandtoe

Has anyone mitigated the CVE-2019-17571 due to socket server class in 1.x log4j ? – Heelandtoe

Link to reference? I can't seem to find where Goers has posted this. – Immunotherapy

You have to trust me. The Goers'answer was posted to me. But this is a link to Bugzilla that says the same thing: bugzilla.redhat.com/show_bug.cgi?id=2031667 – Coppola

What is the conclusion? This quote does not appear to answer the question in any way ("How can I mitigate the Log4Shell vulnerability in version 1.2 of Log4j?" or if it only affects newer versions of Log4j, not this old one). If it does, it is very unclear. Perhaps add some of your own words to the answer? (But without "Edit:", "Update:", or similar - the answer should appear as if it was written today.) – Sindysine

point 2 is clear for me. But summarizing: Log 1.x is secure BUT if you use JMS appender you have to pay attentions. – Coppola