Cannot attach `Log4jHotPatch` agent to official releases of Jenkins

[basil]

Note: All instructions here assume Java 11 (OpenJDK), but I was also able to reproduce the issue with Java 8 (OpenJDK).

Steps to reproduce

• Download an official release of the Jenkins generic Java package (.war).
• Start Jenkins with java -jar jenkins.war.
• Build Log4jHotPatch and run java -Dlog4jFixerVerbose=true -cp Log4jHotPatch.jar Log4jHotPatch ${JENKINS_PID}.

Expected results

Note: These are the actual results with a local (non-official) build of Jenkins:

The Log4jHotPatch agent is attached successfully.

Actual results

The Log4jHotPatch agent cannot be attached:

com.sun.tools.attach.AgentInitializationException: Agent JAR loaded but agent failed to initialize
	at jdk.attach/sun.tools.attach.HotSpotVirtualMachine.loadAgent(HotSpotVirtualMachine.java:165)
	at Log4jHotPatch.loadInstrumentationAgent(Log4jHotPatch.java:228)
	at Log4jHotPatch.main(Log4jHotPatch.java:301)
Error: couldn't loaded the agent into JVM process 546677

The Jenkins logs show:

Exception in thread "Attach Listener" java.lang.SecurityException: class "Log4jHotPatch"'s signer information does not match signer information of other classes in the same package
	at java.base/java.lang.ClassLoader.checkCerts(ClassLoader.java:1151)
	at java.base/java.lang.ClassLoader.preDefineClass(ClassLoader.java:906)
	at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1015)
	at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
	at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:800)
	at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:698)
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:621)
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
	at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:431)
	at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(InstrumentationImpl.java:535)
Agent failed to start!

Evaluation

Stepping through the problematic frames in the debugger, I do not think Jenkins is at fault here. Jenkins contains some classes in the unnamed package namespace:

$ jar tf jenkins.war
[…]
ColorFormatter.class
JNLPMain.class
LogFileOutputStream$1.class
LogFileOutputStream.class
Main$FileAndDescription.class
Main.class
MainDialog.class
[…]
META-INF/JENKINS.RSA
META-INF/JENKINS.SF
META-INF/MANIFEST.MF
[…]
$

Note that META-INF/JENKINS.RSA and META-INF/JENKINS.SF are only present in our signed official releases; a local build will not contain these. The presence of these classes and signatures means that the system class loader associates the signatures with the unnamed package namespace. Then, when Log4jHotPatch attempts to load a class into the same unnamed package namespace without a signature, class loading fails.

I do not think Log4jHotPatch should make any assumptions about whether or not it is free to load unsigned classes into the unnamed package namespace. Perhaps Log4jHotPatch should use its own package namespace instead.

[mohammad-eghlima]

Hi Basil, I am not sure replying is spam here or not but either way!
I have an Amazon Linux 2 with Jdk corretto 8 on it and I get the same error here.

Is there any solution on this?
If i install another JDK or another version of Jenkins?
I am stuck and deadline is approaching!
I appreciate any help.

[basil]

@mohammad-eghlima Based on my analysis above, this is a problem with Log4jHotPatch, not a problem with Jenkins, which is not vulnerable to CVE-2021-44228 in the first place. So if you are concerned with actual security, there is no action to be taken. If you are concerned with shutting up false positives from scanners, remove Log4jHotPatch.

[mohammad-eghlima]

Thanks Basil, I replaced the Corretto jdk 8 with OpenJdk-8 and it solved the issue.
I mean not solving the issue but at least o our server, Jenkins can come up and running.

[basil]

We worked around this problem in Jenkins 2.358 by moving our main class into the executable package namespace so that Log4jHotPatch doesn't trip over it, but this remains a bug for the reasons mentioned in the issue description: Log4jHotPatch should not make any assumptions about whether or not it is free to load unsigned classes into the unnamed package namespace. It should probably use its own package namespace instead.