Mitigating Log4j 2 Vulnerability for Acceldata Products

We are aware of the recently discovered Log4j exploit CVE-2021-44228 and are scanning our code and components for potential exposure. Versions of Log4j 2 that are vulnerable, range from 2.0 to 2.14.1. The first fixed version is 2.15.0.

For its logging API, Acceldata products, Pulse and Torch, use Logback rather than Log4j. However, some of the included components are transitively dependent on Log4j. The following is a list of Docker containers or images that are reliant on this dependency:

1. ad-elastic
2. ad-logstash

In order to mitigate the issue on existing versions of Log4j 2, Acceldata Engineering has prepared a shell script that allows plugging the hole by removing the compromising class and adding an environment variable to the respective Pulse docker containers.

As an additional update to CVE-2021-44228, the fix in version 2.15.0 was insufficient in certain non-default configurations. An additional issue has been identified and is being tracked as CVE-2021-45046. It is recommended to update to 2.16.0 wherever possible, for a more comprehensive fix to this vulnerability.

Acceldata's approach to mitigation for impacted Pulse components:

1. Acceldata customer success representative contacts the users, with the script and the steps to mitigate the issue, as soon as possible.
2. For dependent components, provide a release with upgraded Log4j 2 v2.16.

General Advisory on Workaround for Short Term Mitigation:

The issue can be mitigated in prior releases of Log4j 2 (<2.16.0) by removing the JndiLookup class from the classpath mitigation for CVE-2021-45046 along with the runtime parameter setting mitigation described below:

• Step 1. zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
• Step 2. Add “-Dlog4j.formatMsgNoLookups=true” to JVM start cmd

Advisory for Impacted Docker Containers or Images:

The vulnerable versions of Log4j 2 are present in a number of Docker Official images. Couchbase, elasticsearch, flink, geonetwork, logstash, lightsteamer, neo4j, nuxeo, solar, sonarcube, storm, and xwiki are among those we believe, may contain vulnerable versions of Log4j 2.

If the version of Log4j 2 used in the containerized application is 2.10.0 or later, an environment variable or Java command line option can be used to disable the unsafe substitution behavior. To mitigate, add the following line to the docker file and restart the container:

ENV LOG4J_FORMAT_MSG_NO_LOOKUPS=true