Log4j Vulnerability - Important Note to Performance Engineers

The Internet went crazy last week. If you are an avid user of Tech Twitter, you would have known about the Log4j fiasco. Within a few hours, Log4j vulnerability made headlines on popular news outlets, Twitter, LinkedIn, major organizations' internal forums, Slack channels and more. This blog post is all about Log4j vulnerability for performance engineers about how to mitigate the attack.

What is Apache Log4j Vulnerability CVE-2021-44228?

I am not a security expert. But I closely follow the security news on Twitter and feeds. CVE-2021-44228 is about remote code execution via JNDI lookup.

Apache Log4j is a popular logging framework for Java applications, websites, enterprises, consumer apps and more. Developers log information about security and performance for debugging, audit, and analysis.

By sending the JNDI with LDAP, it is possible to extract or operate the remote server or local machine, if the app is using Log4j 2.0-beta9 to 2.14.1.

There are numerous articles, videos, repos are available to deep-dive into this CVE.

This article targets performance engineers to help out with how to mitigate this vulnerability for the testing tools we are using.

Apache JMeter

The latest version of JMeter 5.4.1 uses Log4j 2.13.3 which is affected by CVE-2021-44228.

There are a couple of options available to mitigate the risk. But it is recommended to follow the Apache Log4j guidelines which are mentioned here.

CVE-2021-44228 solves the problem partially. CVE-2021-45046 prevents attacks by mitigating attackers various patterns.

Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default.

My recommendation is to update the Log4j jars of JMeter to 2.16.0 completely.

Go to JMETER_HOME\lib, delete all the log4j* files.

Download the Log4j zip file from Log4j website.

Extract it and copy the below files and paste it into JMETER_HOME\lib folder.

log4j-1.2-api-2.16.0.jar
log4j-api-2.16.0.jar
log4j-core-2.16.0.jar
log4j-slf4j-impl-2.16.0.jar

JMeter 5.4.2 will be released soon with the bumped up version of Log4j. I will update my post, once it is released.

UPDATE: JMeter 5.4.2 has been released.

Tricentis NeoLoad

Tricentis has released NeoLoad 8.0 with Log4j 2.15.0.

Grafana k6

Grafana's k6 doesn't use Log4j. You are good to go.

MicroFocus LoadRunner and Silk Performer

MicroFocus LoadRunner family is impacted by Log4j vulnerability. Please follow this link to mitigate the risk.

Here is the bulletin link for Silk Performer.

Gatling

Gatling uses logback logging library. If you are using Gatling, you are not affected.

RedLine 13

RedLine13 itself doesn't use Log4j framework. But once JMeter 5.4.2 is out, it will be available on the RedLine13 platform.

EggPlant Performance

If you are using EggPlant Performance, you are NOT affected by the Log4j vulnerability.

Conclusion

It is recommended to update the Log4j libraries with 2.16.0 ASAP. I will keep posting this blog post, if I get any new information.

Log4j developers have been working tirelessly to fix the issues for the past 1 week. A big salute to them from QAInsights.