0

I am remediating my Jetty java apps for CVE-2021-44228 and the other similar log4j findings.

I tried to upgrade to 2.17.0 but not all my apps can upgrade because some of them rely on older version of Jetty that does not work with the new log4j due to the multi-java-release jars (see Error scanning entry META-INF/versions/9/org/apache/logging/log4j/util/StackLocator.class with jetty and log4j 2.9.1?)

Obviously I am working to upgrade those apps to the latest version of Jetty but that is quite involved. It's going to take some time.

So I'm stuck manually remediating the log4j 2.8.2 version (the latest version that is not multi-release format jar).

I have already taken the remediation of the log4j files {nolookups} and added command line argument to disable the JNDI lookups.

I know I can remove JNDILookup.class which helps remediate the major issue.

Is there an official 2.8.2 fork of the fix going anywhere we can use?

Nicholas DiPiazza
  • 10,029
  • 11
  • 83
  • 152
  • 2
    What about using Slf4j with your current log4j and after that works replacing log4j with logback for eg., or some other library that can be upgraded to the latest version in your setup? Because even if you manually fix the cve-2021-44228 there will be plenty more vulnerabilities you'll have to manually patch and in the end you'll spend lots of time – wi2ard Dec 20 '21 at 09:22

1 Answers1

1

If you are also stuck on Java 8 on those old apps, then just repackage those multi-release jar files without their META-INF/versions JAR file directories.

If you using Java 9 or greater, then you are stuck with those META-INF/versions JAR file directories, and this suggestion is not an option for you.

Joakim Erdfelt
  • 46,896
  • 7
  • 86
  • 136
  • I did try that and it seemed to fail with some error deep within the bowels of log4j + jetty. But I didn't spend much time on it. I will try it a bit more. – Nicholas DiPiazza Dec 20 '21 at 16:33