log4j exploit - is it still vulnerable if log4j is maintained in classpath but not actually used in code?

user_6835509 0
Viewed 702

This is regarding vulnerability reported with CVE-2021-44228 against the log4j-core jar and has been fixed in Log4J v2.15.0.

We use Logback API via slf4j. This is confirmed with below code.

final StaticLoggerBinder binder = StaticLoggerBinder.getSingleton();
System.out.println(binder.getLoggerFactory());
System.out.println(binder.getLoggerFactoryClassStr());
//output:
//ch.qos.logback.classic.LoggerContext[default]
//ch.qos.logback.classic.util.ContextSelectorStaticBinder

mvn dependency:tree shows log4j-core API (version <2.15) in classpath (both direct & transitive dependency).

Is the application still vulnerable due to maintaining log4j-core in classpath? Thank you!

log4j java
1 Answers

In order for a vulnerability to be a risk to you, several things need to come together:

  1. the corresponding library exists in your environment
  2. the corresponding library calls do happen in your environment at runtime
  3. 3rd party users figure a way to get their (unchecked) input to that library call

Nobody here can tell you whether "2." and ".3" are applicable in your environment.

But: when you eliminate 1., you know that "2." and "3." are no longer possible. Or the other way round, as long as you 100% convinced that there is no path how a user can enter data into your system that makes it to the corresponding API, then you should be fine even with leaving the library sitting in your environment. But as said, having the library is the mandatory first element of the chain. So while that is present, it is possible that somebody writes code tomorrow that gets you to "2" and "3"!

Thus, keep in mind the perspective of higher management: most likely, the business decision might be: reduce the risk to 0, so make sure you don't even have the corresponding JAR sitting on your machines.

In my bigcorp environment, orders were pretty simple: don't waste any time analysing whether your code uses the corresponding interfaces. When your projects contain the vulnerable JAR, upgrade it immediately. Period.

user_15311240
Related