## https://sploitus.com/exploit?id=C306DCEF-59B3-5147-8169-3674490BD35F
# log4j-CVE-2021-44228-workaround
A. Solution Description
=======================
This project provides a general purpose workaround for the log4j CVE-2021-44228 vulnerability, which can be used in case you do not have the alternative in short term to re-build your respective project or to patch the log4j-core jars.
The idea behind this is quite simple: We force the class loader to load an "empty" version of JndiLookup" class using java runtime "-Xbootclasspath/a" option.
Therefore the whole workaround only consists of this single class "org.apache.logging.log4j.core.lookup.JndiLookup.java" and it has no other dependencies.
There is a pom.xml as well for convenience to compile and jar it via Maven, but you can also do the same simply using your preferred JDK, using "javac" and "jar" commands.
Note that this empty version of "JndiLookup" class cannot be compatible to the original log4j2 implementation, because this would fail in certain class loading situations.
When applying the workaround you would see the following message:
"WARN JNDI lookup class is not available because this JRE does not support JNDI.
JNDI string lookups will not be available, continuing configuration.
Ignoring java.lang.ClassCastException: class org.apache.logging.log4j.core.lookup.JndiLookup"
Log4j2 will continue working without problems nevertheless, just without using any JNDI lookup - there we go - JNDI lookup has been disabled!
Once you have compiled the class and created the jar file just add the "-Xbootclasspath/a:<your workaround ja file location>" option at the beginning of your Java command and point to the directory where you have placed the jar file (e.g. log4j-workaround-1.0-SNAPSHOT.jar). See the proof of concept section for an example of how to do this.
A java command that you would apply this workround to could launch anything (Weblgic, Tomcat, fat jar built by spring, ...).
B. Proof of concept
===================
You can ignore the following if you are just interested in the workaround, but not how to check if it really works.
To validate the approach I have added a "POC" folder, which holds another maven project. I didn't want to use any unit testing, but rather stay close to production set-ups, which use explicit command line launching of fat jars or a container launch as the Tomcat one I have validated it with.
The proof of concept has two classes, "POC.java" to test the workaround on command line and "POCServlet.java" to test the same in an application server.
Both scenarios try to log "${jndi:ldap://localhost/test}", because of which log4j would try to connect to ldap on your local host without the workaround applied and fail the same with connection refused..
To run the commandline POC (once you have built it in Maven):
- Go to the "target\log4j-workaround-1.0-SNAPSHOT\WEB-INF" directory in there and run (if you are on a Windows command line):
java -Xbootclasspath/a:..\\..\\..\\..\target\\log4j-workaround-1.0-SNAPSHOT.jar -classpath classes;lib\\* com.github.grimch.log4j_workaround.poc.POC
To run run the POC with Tomcat:
- First deploy the "log4j-workaround-1.0-SNAPSHOT.war" into the Tomcat "webapps" directory.
- Rather than modifiying the java command, just set the "CATALINA_OPTS" environment respectively:
- Set CATALINA_OPTS=-Xbootclasspath/a:<path-to-log4j-workaround-1.0-SNAPSHOT.jar>
- Then start Tomcat, e.g. using "catalina start".
- Open url http://localhost:8080/log4j-workaround-1.0-SNAPSHOT/POC in your browser.
- Check your terminal or catalina.out for the "WARN JNDI lookup class is not available ..." message.
Final Remarks
=============
Why use "-Xbootclasspath" at all and not just put the workaround jar as the first entry in the "normal" classpath?
Well - some containers let you influence classloading in such a way that jar files in the deployed application archive have preference over the same in the system classpath.
Whatever is in the bootstrap classpath on the other hand has preference over everything else.
If you are sure however that you are not using anything of the same (e.g. "prefer-application-packages" in Weblogic") then you can go for the "-classpath" alternative as well.