19

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
mlissner
  • 17,359
  • 18
  • 106
  • 169

2 Answers2

23

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?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
mlissner
  • 17,359
  • 18
  • 106
  • 169
  • I dont find any log4j files on any of my machines. find / -iname '*log4j*' comes up with nothing - am I ok? – Kalvin Klien Dec 11 '21 at 04:00
  • 2
    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. – Marcono1234 Dec 11 '21 at 14:42
  • 2
    log4j 1.x seems to be vulnerable, if `JMSAppender` is used. See https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126 – Maksim Dec 12 '21 at 14:25
  • 1
    "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. – Scotty J Dec 13 '21 at 04:03
  • @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`). – mlissner Dec 13 '21 at 19:20
  • 2
    @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](https://github.com/apache/logging-log4j2/pull/608#issuecomment-991723301), 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. – mlissner Dec 13 '21 at 19:32
  • @mlissner: I would rather just say : do not configure any usage of JmsAppender in 1.x – Maksim Dec 14 '21 at 08:50
8

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.

robob
  • 1,739
  • 4
  • 26
  • 44
  • We dont use the JMS appender in 1.2, will it still be accessible the logging configuration ? – rinilnath Dec 13 '21 at 13:44
  • 1
    Has anyone mitigated the CVE-2019-17571 due to socket server class in 1.x log4j ? – rinilnath Dec 13 '21 at 13:48
  • 2
    Link to reference? I can't seem to find where Goers has posted this. – trash80 Dec 13 '21 at 18:27
  • 1
    You have to trust me. The Goers'answer was posted to me. But this is a link to Bugzilla that says the same thing: https://bugzilla.redhat.com/show_bug.cgi?id=2031667 – robob Dec 14 '21 at 06:48
  • 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](https://stackoverflow.com/posts/70331452/edit) some of your own words to the answer? (But ***without*** "Edit:", "Update:", or similar - the answer should appear as if it was written today.) – Peter Mortensen Aug 19 '22 at 11:16
  • point 2 is clear for me. But summarizing: Log 1.x is secure BUT if you use JMS appender you have to pay attentions. – robob Aug 21 '22 at 06:38