Update log4j2 to 2.15.0 to fix CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other JNDI related endpoints

[vlsi]

See https://logging.apache.org/log4j/2.x/security.html

[briantully]

Pardon the naive question, but how would one go about integrating this change into an existing JMeter release?
Many thanks in advance!

[FSchumacher]

If you want to patch an existing JMeter release, you can replace the log4j-*-2.x.x.jar files in the lib folder with those of a version 2.15.0 or newer.

[vlsi]

An alternative option is to delete JndiLookup.class: https://twitter.com/yazicivo/status/1469394008510279680

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

[briantully]

If you want to patch an existing JMeter release, you can replace the log4j-*-2.x.x.jar files in the lib folder with those of a version 2.15.0 or newer.

Thank you @FSchumacher ! Will JMeter automatically update the ClassPath with the new filenames or is it using some kind of regex to pull in those JAR files?

[briantully]

An alternative option is to delete JndiLookup.class: twitter.com/yazicivo/status/1469394008510279680

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Thank you, @vlsi! I'll give that a try if replacing the log4j JAR files doesn't work. Much appreciated.

[vlsi]

It loads all the jar files, so new names would work just fine:

jmeter/src/launcher/src/main/java/org/apache/jmeter/NewDriver.java

Lines 98 to 102 in 4038421

	File[] libDirs = new File[] { new File(JMETER_INSTALLATION_DIRECTORY + File.separator + "lib"),// $NON-NLS-1$ $NON-NLS-2$
	new File(JMETER_INSTALLATION_DIRECTORY + File.separator + "lib" + File.separator + "ext"),// $NON-NLS-1$ $NON-NLS-2$
	new File(JMETER_INSTALLATION_DIRECTORY + File.separator + "lib" + File.separator + "junit")};// $NON-NLS-1$ $NON-NLS-2$
	for (File libDir : libDirs) {
	File[] libJars = libDir.listFiles((dir, name) -> name.endsWith(".jar"));

[briantully]

@vlsi - Большое спасибо! :)

[mazen160]

Any ideas or ETA when would the public release be there with the security fix included?

[briantully]

Any ideas or ETA when would the public release be there with the security fix included?

@mazen160 rather than wait for a new release (and potentially new bugs) you can follow the advice given by @FSchumacher and @vlsi above and download the new log4j 2:16.0 release at https://logging.apache.org/log4j/2.x/download.html and replace the JAR files that JMeter uses, which you can find in $JMETER_HOME/libexec/lib/log4j-*

There are 4 JAR files to replace:

• log4j-1.2-api-2.x.x.jar
• log4j-api-2.x.x.jar
• log4j-core-2.x.x.jar
• log4j-slf4j-impl-2.x.x.jar

Just delete the existing log4j-* JAR files in $JMETER_HOME/libexec/lib and then copy over the 4 similarly named files from the 2.16.0 download into $JMETER_HOME/libexec/lib.

I did this with my old JMeter 5.2.1 install and it worked like a charm :)

@vlsi I know this pull request was merging in version 2.15.0 of log4j, but based on the changelog for log4j, it seems as though the CVE fix is actually in the 2.16.0 release:
https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0

Here is the log4j ticket detailing the fix (disabling JNDI by default) for CVE-2021-44228 that is included in the 2.16.0 release.

[kevin-imbus]

I can confirm that @FSchumacher's suggestion works with JMeter 5.4.1 and log4j 2.16.0. Thank you!

@vlsi Many thanks for your fix! :)

Edit: Also works flawlessly with the JMeter Plugins Manager and installed plugins like the Flexible File Writer

[edw013]

hi all, I'm getting the following error when replacing the log4j JAR files:
2021-12-14 22:06:27,876 WARN o.a.j.r.ClassFinder: Can not open the jar /opt/apache-jmeter-5.4.1-PATCH/lib/ext/._ApacheJMeter_functions.jar, message: zip END header not found java.util.zip.ZipException: zip END header not found

This happens for all the files in the /lib/ext/ folder, any idea why they might be affected? The steps I did were:

1. Download and extract JMeter 5.4.1 tgz
2. Download and extract log4j 2.16.0 tgz
3. Replace the 4 jars in jmeter/lib/
4. Create a new tgz from there (I host it elsewhere, and this issue comes from downloading this file again and extracting it then running)

edit: it seems to work fine up until the creating a new tgz step, any advice on that?
edit2: comment below solved it for me, something weird was going on with creating the tarball on MacOS

[rainerjung]

Note the leading dot "." in the file name contained in the message. Maybe a broken operating system like MacOS added such unwanted additional files to the directory which then got included in your new tarball, but are not really jar files but instead OS specific metadata files. For the rest of the world such files are garbage leading to unwanted behavior.

[sebiboga]

in case you're running JMeter in Windows, I wrote a batch file that automate what you need to do;
documentation and instructions can be found here - of course steps are implemented based on all previous comments.

https://dev.to/sebiboga/jmeter-541-fix-for-security-cve-2021-44228-issue-4joc

[kevin-imbus]

Quick reminder that there are unreleased nightly builds for JMeter available that you can use at your own risk :)

https://ci.apache.org/projects/jmeter/nightlies/

[vlsi]

The fix is available in JMeter 5.4.2: https://lists.apache.org/thread/bskl3n41ty0x3mvt92548xyxds2vsk6s

[psmietanaa]

@vlsi Do you plan to update log4j to 2.16 to fix CVE-2021-45046?

[sebiboga]

@psmietanaa it's already updated in JMeter 5.4.2 (I just checked)

[vlsi]

For reference, the update to 2.16.0 is bdc610a + 0551e4c

[vlsi]

Vladimir: If we wait a bit we can bump to 2.17 :)

🙀 this is not fun: https://issues.apache.org/jira/browse/LOG4J2-3230 Certain strings can cause infinite recursion