nccgroup / log4j-jndi-be-gone Goto Github PK

This project would be a lot more useful for mitigating the log4j 2.x JndiLookup vulnerability if it offered RPMs that can easily be installed on Linux systems that would impact the system wide installation of java and would hook into systemd to provide a default environment for initiating the java agent.

Gradle can easily support RPM packaging using the nebula.rpm plugin.

The systemd environment can use the _JAVA_OPTIONS environment variable to define the agent which should work from Java 6 through Java 17 though it's deprecated from Java 9 onward.

The RPM would include configuration files to setup the systemd default environment and the interactive login profile. It would also include a post installation scriptlet to trigger systemd to update to the _JAVA_OPTIONS environment and a post removal scriptlet to remove the _JAVA_OPTIONS environment.

Good morning, I'm having a heck of a time trying to test this to get proof positive results that it works. I have added a controller endpoint to our application called /exploitme, which only does one thing, and that's print the request's headers and then exits.

In my test case, I do a get against that endpoint with a user-agent header of ${jndi:ldap://127.0.0.1/o=reference}' and I see that being dumped by my controller, but I do not see anything in my logs that log4j-jndi-be-gone has blocked anything. For what it's worth, the javaagent is loaded, has the correct permissions and I know for a fact that my application is using a vulnerable version of log4j2.

For what it's worth, this is running on a tomcat 8 server using openjdk 1.8 on RHEL. Any insights would be greatly appreciated.

The agent checks for the fully qualified path to the JNDILookup class. Normally this will work fine, however if the application the agent is protecting was compiled using the maven-shade plugin the log4j class package paths could have been rewritten. So instead of
"org.apache.logging.log4j.core.lookup.JndiLookup"
It might become
"com.example.org.apache.logging.log4j.core.lookup.JndiLookup"
In this case the agent will fail to protect against the JNDI lookup vulnerability.

So instead of
return "org.apache.logging.log4j.core.lookup.JndiLookup".equals(target.getCanonicalName());
it was changed to check that the target.getCanonicalName() ends with "org.apache.logging.log4j.core.lookup.JndiLookup" this should protect against this vulnerability.

This is a cross-reference post to an issue I made in bytebuddy: raphw/byte-buddy#1179

We're trying to run this in our environment and having some issues. I'm not an expert in javaagents/bytebuddy so I'm hoping to get some help here, or maybe suggest some improvements to this repo.

Is this agent being built with the latest version of bytebuddy? I see a min version is being defined here, but unsure how that plays into it all: https://github.com/nccgroup/log4j-jndi-be-gone/blob/main/build.gradle#L18

Something that was suggested in that other issue is shading ByteBuddy so there wouldn't be a potential conflict with something else on the classpath. Is this something that would be doable?

When running our application with the following JAVA_OPTS:

-javaagent:/opt/datadog/dd-java-agent.jar -javaagent:/opt/log4j-jndi-be-gone/log4j-jndi-be-gone.jar '

We get the following in some of our applications:

Exception in thread "main" java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:500)
	at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:512)
Caused by: java.lang.IllegalAccessError: tried to access field net.bytebuddy.dynamic.Nexus.NO_QUEUE from class net.bytebuddy.dynamic.NexusAccessor
	at net.bytebuddy.dynamic.NexusAccessor.<init>(NexusAccessor.java:68)
	at net.bytebuddy.agent.builder.AgentBuilder$InitializationStrategy$SelfInjection$Split.<init>(AgentBuilder.java:3169)
	at net.bytebuddy.agent.builder.AgentBuilder$Default.<init>(AgentBuilder.java:8397)
	at net.bytebuddy.agent.builder.AgentBuilder$Default.<init>(AgentBuilder.java:8385)
	at trust.nccgroup.jndibegone.hooks.JndiLookup__lookup.hook(JndiLookup__lookup.java:51)
	at trust.nccgroup.jndibegone.Agent.load(Agent.java:26)
	at trust.nccgroup.jndibegone.PreMain.premain(PreMain.java:27)
	... 6 more
FATAL ERROR in native method: processing of -javaagent failed
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f6ab2ef0324, pid=1, tid=11
#
# JRE version: OpenJDK Runtime Environment (9.0+12) (build 9.0.4+12-Debian-4)
# Java VM: OpenJDK 64-Bit Server VM (9.0.4+12-Debian-4, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# C  [libc.so.6+0x36324]  abort+0x244

Any help would be appreciated!