log4j-jndi-be-gone: A simple mitigation for CVE-2021-44228
Summary
tl;dr Run our new tool by adding to all of your JVM Java stuff to stop log4j from loading classes remotely over LDAP. Meanwhile, even without JNDI, if someone has access to your log4j output (wherever you send it), and can cause their input to end up in a log4j call (pretty much a given based on the current havoc playing out) they can systematically dump all sorts of process and system state into it including sensitive application secrets and credentials. None of these solutions are ideal because they all presume that everyone has a 100% handle on their dependency chains and that you won’t end up with a mix of log4j versions strewn across the subcomponents of apps segmented across multiple classloaders (looking at you, WAR files). To try to make the situation a little bit more manageable in the meantime, we are releasing log4j-jndi-be-gone, a dead simple Java agent that disables the log4j JNDI handler outright. The benefit of this Java agent is that a single command line flag can negate the vulnerability regardless of which version of log4j is in use, so long as it isn’t obfuscated (e.g. with proguard), in which case you may not be in a good position to update it anyway.
