Three ways to patch Log4Shell CVE-2021-44228 vulnerability

Three ways to patch Log4Shell CVE-2021-44228 vulnerability

As you may have heard over the news, a new vulnerability (CVE-2021-44228) was discovered in Log4j 2 library by Alibaba. This zero-day vulnerability allows remote code execution and potentially affect millions of services across the globe. In this article, we go through three possible ways to patch Log4Shell CVE-2021-44228 vulnerability.

Update on 11 December 16:10 UTC: two more mitigation strategies (number 4 and 5) were added.

Update on 14 December 13:45 UTC: log4j-detector and Amazon Hotpatch were added.

Are you impacted?

The first thing is to figure out whether your code is affected by the vulnerability. Any codebase that uses any version of Log4j between 2.0 and 2.14.1 is vulnerable to this exploit.

This vulnerability does not apply to JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 according to LunaSec. But that doesn’t make it much safer since other attack possibilities can result in remote code execution exploit anyway.

Note that although your code may not use Log4j, chances are one of the libraries you include in your code uses it. In that case, your code is still affected as the transitive dependency (Log4j) is pulled and included in your project automatically. If you are unsure, try getting the dependency tree (mvn dependency:tree on maven projects) of your code. Then search for org.apache.logging.log4j.

For quick detection, you can use the log4j-detector utility that detects log4j versions on your file system, including deeply recursively nested copies (zips inside zips).

Additionally, you can use the Maven OWASP Dependency-Check plugin and scan your code. For the plugin configuration check this guideline.

Possible patches

There are multiple ways to fix this vulnerability depending on your case. In this section, we cover the most viable (including short-terms) options.

1. Redirect your traffic to Cloudflare (not recommended)

It is the quickest, dirtiest, and easiest fix to buy you enough time to put a real fix in place. Cloudflare has already deployed mitigation rules to block the exploit attempts.

Cloudflare announcement on Log4Shell fix

For more details, see here

2. Upgrade to Log4j 2.15.0 (recommended)

It’s easier said than done as the latest Log4j version only works with JDK8 and newer. That may not be a viable option for codebases relying on older JDK versions.

If your code directly uses Log4j and is not that ancient, go ahead and update the library. It’s backward compatible and shouldn’t break anything.

2.1. Log4j as transitive dependency

For the case of transitive dependency, check the library/framework site for any updates first.

The following is the (incomprehensive) list of well-known projects that are affected by Log4Shell vulnerability (source).

  • Apache Druid
  • Apache Dubbo
  • Apache Flink
  • Apache Flume
  • Apache Hadoop
  • Apache Kafka
  • Apache Solr
  • Apache Spark
  • Apache Struts
  • Apache Tapestry
  • Apache Wicket
  • Elastic Elasticsearch
  • Elastic Kibana
  • Elastic Logstash
  • Ghidra
  • Grails
  • Minecraft

The following libraries/frameworks don’t appear to use Log4j by default, though they may optionally be configured to use it.

  • Apache Tomcat
  • Dropwizard
  • Hibernate
  • JavaServer Faces
  • Oracle ATG Web Commerce
  • Spring Framework

You can either wait for project maintainers to release new versions (if they have not already). Or you can go ahead and patch affected libraries manually in the meantime, which is a bit time-consuming and requires some trials and errors.

Below is an example of how to fix Log4j exploit on Apache Struts,

3. Use Log4j Patch(er) agents

If updating your codebase is not an option for you, the final alternative is to add a Log4j agent patcher to your project that disables all lookup() conversions.

At the moment there are two projects available for that:

Amazon has also created a new a Hotpatch agent for Apache Log4j that’s extremely useful if you can’t afford to restart your JVM process. Source code over GitHub, here.

4. Disable formatMsgNoLookups (only for Apache Log4j >= <code>2.10.0)

If you use the Log4j version between 2.10.0 and 2.14.1, and can not upgrade to 2.15.0, you can disable message lookup by setting either the system property (source).

log4j2.formatMsgNoLookups=true

Or the environment variable to true.

LOG4J_FORMAT_MSG_NO_LOOKUPS=true

5. Remove JndiLookup class (2.0-beta9 <= Apache log4j <= 2.10.0)

JndiLookup class should be removed for code that use Log4j older than 2.10.0 and cannot upgrade to 2.15.0.

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

What’s the best approach

The best approach is to upgrade to Log4j 2.15.0 and even better upgrading your JDK to the latest supported version (whether minor or major) on top of that. If that’s not possible, your next best options are numbers two, four, five, and three respectively. Number two, four, and five are official mitigations provided by Apache.

I do highly recommend against using the number one approach (unless for a very brief time) as it doesn’t fix the actual problem.

That’s all about on three approaches to patch Log4Shell CVE-2021-44228 vulnerability. Stay safe!

Update logs

  • 11 December 16:10 UTC
    • Added two more mitigation strategies
    • Added what’s the best approach section
    • Updated references
  • 13 December 13:45 UTC
    • Added log4j-detector (a quick way to find log4j on a project) to are you impacted section
    • Added Amazon Hotpatch for Apache Log4j to Use Log4j Patch(er) agents section
    • Fixed version typo on section 4

Other references

Inline/featured images credits

3 thoughts on “Three ways to patch Log4Shell CVE-2021-44228 vulnerability

  1. Should this line be “>=”, ——————————————=,

    4. Disable formatMsgNoLookups (only for Apache Log4j <= 2.10.0)
    If you use the Log4j version between 2.10.0 and 2.14.1,

Comments are closed.