Workaround instructions to address CVE-2021-44228: Apache Log4j Remote Code Execution for GemFire

Products

• VMware Tanzu Gemfire

Issue/Introduction

A critical vulnerability in Apache Log4j identified by CVE-2021-44228 has been disclosed that may allow for remote code execution. VMware has classified this issue as critical and is prioritizing publishing fixes and workarounds.

CVE-2021-44228 has been determined to impact GemFire (all versions) via the Apache Log4j open source component it ships.

This vulnerability and its impact on VMware products are documented in the following VMware Security Advisory (VMSA). Review VMware Response to CVE-2021-44228: Apache Log4j Remote Code Execution (87068) before continuing.

Environment

Product Version: 9.1
OS: ALL

Resolution

IMPORTANT UPDATE:

We have recently discovered that the log4j2.formatMsgNoLookups=true workaround will NOT sufficiently protect against all currently know vulnerabilities. Hence, additional steps need to be taken. Our updated mitigation steps, for now, are as follows:

1. Each GemFire process (member or client) will need to be stopped.

2. Delete all JndiLookup class files from jars and war files, e.g.: 

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

3. After modifying the jars, restart the process.

As you may be aware, another CVE-2021-45046 has been discovered against log4j 2.15. We are now going to be releasing new product on supported versions incorporating log4j 2.16.

NOTE: All of this content applies to GemFire clients as well. It is not only the GemFire Server side version that must be updated to eliminate the potential impact, whether using a workaround known to work, or using an upgrade of GemFire product in your environments.


LATEST UPDATE:  December 16

Some have had issues following these above mitigation steps. Thus, we are updating the article to be more clear. In addition, we are addressing how to alter the PULSE WAR file also to mitigate, as necessary.   

As you can see above, the suggestion was to use the zip command, and that still holds.
 

IF USING ZIP:

First:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Second: To address PULSE using zip, from the $GEMFIRE/tools/Pulse directory, do:
1. $ unzip geode-pulse-*.war WEB-INF/lib/log4j-core-\*.jar
2. $ zip -q -d WEB-INF/lib/log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
3. $ zip -u geode-pulse-9.10.9.war WEB-INF/lib/log4j-core-\*.jar
4. $ rm -rf WEB-INF

=========

 

IF USING JAR:

IF "zip" is not an option for you, we think the following will achieve what you are needing to do:

First:
$ mkdir exploded-jar
$ cd exploded-jar
$ jar -xvf /path/to/gemfire/lib/log4j-core-${log4jVersion}.jar
$ rm org/apache/logging/log4j/core/lookup/JndiLookup.class
$ jar -Mcvf /path/to/gemfire/lib/log4j-core-${log4jVersion}.jar .
$ cd ..
$ rm -rf exploded-jar

Second: (Addressing Pulse)
$ mkdir exploded-war
$ cd exploded-war
$ jar -xvf /path/to/gemfire/tools/Pulse/geode-pulse-${gemfireVersion}.war
$ cp /path/to/gemfire/lib/log4j-core-${log4jVersion}.jar
$ jar -Mcvf /path/to/gemfire/tools/Pulse/geode-pulse-${gemfireVersion}.war .
$ cd ..
$ rm -rf exploded-war

===================

NOTE: All of this content applies to GemFire clients as well. It is not only the GemFire Server side version that must be updated.