1

If a version of log4j2 is present on a server (say, 2.5 or 2.7) but the JndiLookup class does not exist in any jars, does this mean this specific implementation of log4j2 is not vulnerable to Log4Shell?

Anders
  • 64,406
  • 24
  • 178
  • 215
Marcel
  • 121
  • 4
  • 1
    That is my understanding. You might find this blog helpful: https://nakedsecurity.sophos.com/2021/12/13/log4shell-explained-how-it-works-why-you-need-to-know-and-how-to-fix-it/ – Stephen Fowler Dec 14 '21 at 23:53

2 Answers2

1

According to the post here (thanks @Stephen Fowler):

Apache has proposed three different workarounds in case you can’t update yet; we tried them all and found them to work.

One of the options are:

C. Repackage your log4j-core-*.jar file by unzipping it, deleting the component called org/apache/logging/log4j/core/lookup/JndiLookup.class, and zipping the other files back up again.

It stands to reason that if the JndiLookup.class does not exist, that the feature needed by the exploit doesn't exist, and therefore the environment is not susceptible to Log4Shell.

Marcel
  • 121
  • 4
0

No

If you happen to have a jar that doesn't contain some classes that should be there, you are running a code that someone has tampered with.

In that case you have absolutely no idea what is running on your system, and what potential bugs and backdoors are there.

Except you've modified it yourself, but in that case you wouldn't ask.

Never download modified version of the somewhere from some random page where someone claims this version is modified to fix the problem!

This is the easy way an attacker can exploit your panic to break into your system.

Danubian Sailor
  • 348
  • 2
  • 10
  • The absence of the JndiLookup.class does not mean that it was tampered with. It may just mean that whatever implementation was done just doesn't include it, since its not needed. Valid advice regarding sources of software, but misplaced in this instance IMHO. – Marcel Dec 17 '21 at 14:31