Updated on January 7, 2021 with additional information on the evolving vulnerability.
Protecting our customers, prospects and community members and their data from malicious activity is a top priority for GridGain. Here’s what we currently know about Apache Log4j Remote Code Execution Vulnerability CVE-2021-44228 commonly known as “Log4Shell” and the additional remote code execution vulnerabilities CVE-2021-45046 and CVE-2021-45105.
GridGain's Consolidated Response
Upon discovery of each vulnerability, GridGain's engineering and security teams investigated impacts to GridGain's internal systems, GridGain's commercial software releases and Apache Ignite open source releases. Below are important facts you need to know about mitigating risks from the Log4j vulnerabilities with your GridGain and Apache Ignite deployments.
- Per vulnerability report CVE-2021-44228, Log4j versions 2.0 through 2.14.1 “do not protect against attacker-controlled LDAP and other JNDI related endpoints.” An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.The vulnerability was partially corrected in Log4j 2.15 and later versions, which are now available from the Apache Software Foundation
- Per vulnerability report CVE-2021-45046, it was found that the fix addressing CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete for certain non-default configurations.
- Per vulnerability report CVE-2021-45105, Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3) did not protect from uncontrolled recursion from self-referential lookups.
- The GridGain Nebula SaaS platform has been updated to address documented vulnerabilities.
- Gridgain Community, Enterprise and Ultimate versions 8.7.42 and 8.8.13, are now available and mitigate these Log4j vulnerabilities. The fixes are included in Apache Ignite 2.11.1.
- Customers and community members running GridGain Community, Enterprise or Ultimate versions 8.7.40, 8.8.11 or earlier (including GridGain for z/OS platform), or Apache Ignite 2.11 and earlier should take proactive steps, described below, to mitigate the Log4j vulnerabilities. The GridGain servers and clients must be restarted after applying the workaround and/or patches.
- Current mitigation options are:
- removing JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class, or
- upgrading Log4j2 dependency to 2.17.
Importantly, previous documented work-arounds such as setting a configuration parameter do not work and are no longer recommended.
- The following script could be used to clean vulnerable jars:
cd $IGNITE_HOME
# Print candidates for patching
for f in $(find . -name '*log4j*.jar'); do unzip -l $f | grep -q JndiLookup && echo $f; done
# Apply fix
for f in $(find . -name '*log4j*.jar'); do unzip -l $f | grep -q JndiLookup && echo $f && zip -q -d $f org/apache/logging/log4j/core/lookup/JndiLookup.class; done
# Restart your cluster
- Current mitigation options are:
- None of GridGain's internal systems have been compromised by this vulnerability and no intrusions have been detected.
GridGain customers who have additional questions about managing their GridGain clusters and mitigating the Log4j vulnerabilities should contact GridGain Support through normal channels.