GridGain Systems Support
How can we help you today?
Security Updates Announcements
[CVE-2017-14614] GridGain Visor GUI Console - File System Path Traversal
Severity: Important
Vendor: GridGain Systems
Versions Affected:
* GridGain 8.1.4 and earlier
* GridGain 1.9.6 and earlier
* GridGain 1.8.11 and earlier
* GridGain 1.7.15 and earlier
Impact:
user needs to provide a path to the files. Visor does not sanitize the path provided that might result in an unauthorized access to sensitive files.
Description:
Mitigation:
Start cluster nodes under a system user that has restricted access to the file system.
In addition, to make the cluster more secure consider using GridGain’s Security module setting up basic authentication and authorization parameters.
Upgrade to the versions below to enable the path sanitization by default:
* GridGain 8.1.5 or later
* GridGain 1.9.7 or later
* GridGain 1.8.12 or later
* GridGain 1.7.16 or later
References:
* http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14614
Dear GridGain customers,
Recently discovered Meltdown and Spectre vulnerabilities might affect your GridGain deployments. Please refer to the blog post below for suggestions on how to protect from the security breaches:
Regards,
Denis Magda
Product Management
Dear GridGain customers,
GridGain's performance team applied security patches against the notorious Meltdown Spectre vulnerabilities and completed performance testing of general operations and workloads that are typical for GridGain deployments.
The security patches against the Meltdown and Spectre vulnerabilities showed a negligible impact to GridGain performance. Please find the results and more details here: https://www.gridgain.com/resources/blog/meltdown-and-spectre-patches-show-negligible-impact-gridgain-performance
Thus, the GridGain performance team highly recommends its customers and partners to consider security patches for CVE-2017-5754 (Meltdown) and CVE-2017-5753 (Spectre Variant 1) in their deployment environments and contact our support team if you run into a larger performance drop in your use case.
Best regards,
GridGain Product Management
CVE-2018-1295: Possible Execution of Arbitrary Code Within Deserialization Endpoints of Apache Ignite
Severity: Important
Vendor: GridGain, Inc.
Versions Affected:
* Apache Ignite 2.3 and earlier
* GridGain Professional Edition 2.4.2 and earlier
* GridGain Enterprise and Ultimate Editions 8.3.3 and earlier
Impact:
An attacker can execute arbitrary code on Apache Ignite and GridGain nodes in the case when the classpath contains arbitrary vulnerable classes.
Description:
Apache Ignite serialization mechanism does not have a list of classes allowed for serialization/deserialization, which makes it possible to run arbitrary code when 3-rd party vulnerable classes are present in Ignite classpath. The vulnerability can be exploited if the one sends a specially prepared form of a serialized object to one of the deserialization endpoints of some Ignite components - discovery SPI, Ignite persistence, Memcached endpoint, socket steamer.
Mitigation:
• All Ignite versions: make sure there are no vulnerable classes among your custom code used in GridGain.
• Upgrade to GridGain Professional Edition 2.4.3, GridGain Enterprise or Ultimate Edition 8.3.4 or later and use IGNITE_MARSHALLER_WHITELIST and/or IGNITE_MARSHALLER_BLACKLIST system properties to define classes allowed for deserialization
Credit:
The vulnerability was discovered by Man Yue Mo of lgtm.com.
References:
* http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1295
Sincerely yours,
GridGain Team
[CVE-2014-0114]: GridGain is vulnerable to existing CVE-2014-0114
Severity: Important
Vendor: GridGain, Inc.
Versions Affected:
- GridGain Professional Edition 2.5.1 or earlier
- GridGain Ultimate and Enterprise Editions 8.5.1 or earlier
Impact:An attacker can execute arbitrary code on GridGAin nodes in the case when GridGain classpath contains arbitrary vulnerable classes.
Description:GridGain used commons-beanutils-1.8.3.jar library which did not suppress the class property, which allowed remote attackers to "manipulate" the ClassLoader and execute arbitrary code via the class parameter, as demonstrated by the passing of this parameter to the getClass method of the ActionForm object in Struts 1.
Mitigation:
- All GridGain versions: make sure there are no vulnerable classes among your custom code used in GridGain.
- Upgrade to GridGain Professional Edition 2.5.2 or later, GridGain Enterprise and Ultimate Edition 8.5.2 or later.
References:
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0114
--
Denis Magda,On behalf of GridGain team.
Alexander Gerus
[CVE-2018-8018] Possible Execution of Arbitrary Code via Apache Ignite GridClientJdkMarshaller
Severity: Important
Vendor: GridGain Systems
Versions Affected:
- GridGain Professional Edition 2.4.7 or earlier
- GridGain Ultimate and Enterprise Editions 8.4.7 or earlier
Impact:
An attacker can execute arbitrary code on Ignite nodes via GridClientJdkMarshaller deserialization endpoint in the case when Ignite classpath contains arbitrary vulnerable classes.
Description:
Apache Ignite serialization mechanism does not have a list of classes allowed for serialization/deserialization, which makes it possible to run arbitrary code when 3-rd party vulnerable classes are present in Ignite classpath. The vulnerability can be exploited if the one sends a specially prepared form of a serialized object to GridClientJdkMarshaller deserialization endpoint.
Mitigation:
• All GridGain versions: make sure there are no vulnerable classes among your custom code used in GridGain
- Ignite Professional Edition 2.4.7 or earlier users: upgrade to Ignite 2.4.8 or later version
- Ignite Ultimate and Enterprise Editions 8.4.7 or earlier users: upgrade to Ignite 8.4.8 or later version
After version upgrade use IGNITE_MARSHALLER_WHITELIST and/or IGNITE_MARSHALLER_BLACKLIST system properties to define classes allowed for deserialization. Refer to documentation for more details:
https://apacheignite.readme.io/docs/securing-data-deserialization
Credit:
- The vulnerability was discovered by Man Yue Mo of lgtm.com
Reference:
--
Alexander Gerus, On behalf of GridGain team.
Alexander Gerus
[CVE-2018-1273] [CVE-2018-1274] Apache Ignite impacted by security vulnerability in Spring Data Commons
Severity: Important
Vendor: GridGain Systems
Versions Affected:
- GridGain Professional Edition 2.4.7 or earlier
- GridGain Ultimate and Enterprise Editions 8.4.7 or earlier
Impact:
An unauthenticated remote malicious user (or attacker) can issue requests against Spring Data REST or Spring Data
Description:
Apache Ignite utilizes Spring Data Common library for some of its components. The vulnerability affects Apache Ignite users who us Spring Data REST for access an Ignite cluster via HTTP and Spring Data. Spring Data Commons, versions prior to 1.13 to 1.13.10, 2.0 to 2.0.5, and older unsupported versions, contain a property binder vulnerability caused by improper neutralization of special elements. An unauthenticated remote malicious user (or attacker) can supply specially crafted request parameters against
Spring Data REST backed HTTP resources or using Spring Data’s projection-based request payload binding hat can lead to a remote code execution attack.
Mitigation:
- GridGain Professional Edition 2.4.7 or earlier users: upgrade to Ignite 2.4.8 or later version
- GridGain Ultimate and Enterprise Editions 8.4.7 or earlier users: upgrade to Ignite 8.4.8 or later version
Credit:
- Harendra Rai of NCR Corporation discovered the impact of the existing vulnerability on Apache Ignite.
Reference:
CVE-2020-1963: Apache Ignite access to file system through predefined H2 SQL functions
Severity: Critical
Vendor:
GridGain Systems
Versions Affected:
- GridGain Professional Edition 2.4.16 and earlier, 2.5.18 and earlier
- GridGain Community Edition 8.7.14 and earlier
- GridGain Enterprise Edition 8.4.16 and earlier, 8.5.18 and earlier, 8.7.14 and earlier
- GridGain Ultimate Edition 8.4.16 and earlier, 8.5.18 and earlier, 8.7.14 and earlier
Impact:
An attacker can use embedded H2 SQL functions to access a filesystem for write and read.
Description:
GridGain uses H2 database to build SQL distributed execution engine. H2 provides SQL functions which could be used by attacker to access to a filesystem.
Mitigation:
Users of affected versions should upgrade to newer versions:
- GridGain Professional Edition 2.4.17 or later, 2.5.19 or later
- GridGain Community Edition 8.7.15 or later
- GridGain Enterprise Edition 8.4.17 or later, 8.5.19 or later, 8.7.15 or later
- GridGain Ultimate Edition 8.4.17 or later, 8.5.19 or later, 8.7.15 or later
In case SQL is not used at all the issue could be mitigated by removing ignite-indexing.jar from GridGain classpath.
Risk could be partially mitigated by using non-privileged user to start GridGain.
Credit:
This issue was discovered by Sriveena Mattaparthi of ekaplus.com
Vladimir Pligin
CVE-2021-28164
Severity: Medium
Vendor:
GridGain Systems
Versions Affected:
- GridGain Community Edition 8.7.34 and earlier, 8.8.3 and earlier
- GridGain Enterprise Edition 8.7.34 and earlier, 8.8.3 and earlier
- GridGain Ultimate Edition 8.7.34 and earlier, 8.8.3 and earlier
Impact:
An attacker can reveal sensitive information regarding the implementation of a web application.
Description:
GridGain uses Eclipse Jetty in order to serve REST requests. In Eclipse Jetty 9.4.37.v20210219 to 9.4.38.v20210224, the default compliance mode allows requests with URIs that contain %2e or %2e%2e segments to access protected resources within the WEB-INF directory. For example a request to /context/%2e/WEB-INF/web.xml can retrieve the web.xml file. This can reveal sensitive information regarding the implementation of a web application.
Mitigation:
Users of affected versions should upgrade to newer versions:
- GridGain Community Edition 8.7.35 or later, 8.8.4 or later
- GridGain Enterprise Edition 8.7.35 or later, 8.8.4 or later
- GridGain Ultimate Edition 8.7.35 or later, 8.8.4 or later
In case REST is not used at all the issue could be mitigated by removing ignite-rest-http.jar from GridGain classpath.
CVE-2021-44228
Severity: Critical
Vendor:
Apache Software Foundation
Versions Affected:
GridGain Community Edition 8.7.40 and earlier, 8.8.11 and earlier
GridGain Enterprise Edition 8.7.40 and earlier, 8.8.11 and earlier
GridGain Ultimate Edition 8.7.40 and earlier, 8.8.11 and earlier
Impact:
Allows a remote attacker to execute arbitrary code on the server if the system logs an attacker-controlled string value with the attacker's JNDI LDAP server lookup.
Description:
Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters 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. From log4j 2.15.0, this behavior has been disabled by default. In previous releases (>2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to "true" or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
Mitigation:
GridGain users who utilize log4j2 logging must upgrade log4j2 dependency, or apply workaround available below and apply the next release which will include the updated log4j2 dependency. The GridGain servers and clients must be restarted after applying the WA and/or patches.
In Log4j 2.15.0 this feature is now disabled by default. While an option has been provided to enable Lookups in this fashion, users are strongly discouraged from enabling it.
Users who cannot upgrade to 2.15.0 can mitigate the exposure by:
a) Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as a command line option or add log4j.formatMsgNoLookups=true to a log4j2.component.properties file on the classpath to prevent lookups in log event messages.
b) Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event messages.
c) Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the JndiContextSelector and JMSAppender to no longer function.
Reference:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
CVE-2021-44228
Severity: Critical
Vendor:
Apache Software Foundation
Versions Affected:
GridGain Control Center 2021.08.01 and earlier.
Impact:
Allows a remote attacker to execute arbitrary code on the server if the system logs an attacker-controlled string value with the attacker's JNDI LDAP server lookup.
Description:
Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters 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. From log4j 2.15.0, this behavior has been disabled by default. In previous releases (>2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to "true" or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
Mitigation:
Current GridGain Control Center users who utilize log4j2 logging must upgrade log4j2 dependency, or apply workaround available below and apply the next release of GridGain Control Center On-Premise which will include the updated log4j2 dependency. The GridGain Control Center must be restarted after applying the WA and/or patches.
In Log4j 2.15.0 this feature is now disabled by default. While an option has been provided to enable Lookups in this fashion, users are strongly discouraged from enabling it.
Users who cannot upgrade to 2.15.0 can mitigate the exposure by:
a) Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as a command line option or add log4j.formatMsgNoLookups=true to a log4j2.component.properties file on the classpath to prevent lookups in log event messages.
b) Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event messages.
c) Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the JndiContextSelector and JMSAppender to no longer function.
Reference:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
CVE-2021-44228
Severity: Critical
Vendor:
Apache Software Foundation
Versions Affected:
GridGain Web Console 2021.04.00 and earlier.
Impact:
Allows a remote attacker to execute arbitrary code on the server if the system logs an attacker-controlled string value with the attacker's JNDI LDAP server lookup.
Description:
Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters 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. From log4j 2.15.0, this behavior has been disabled by default. In previous releases (>2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to “true” or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
Mitigation:
Current Web Console users who utilize log4j2 logging must upgrade log4j2 dependency, or apply one of the workarounds available below. The GridGain Web Console must be restarted after applying the WA and/or patches.
In Log4j 2.15.0 this feature is now disabled by default. While an option has been provided to enable Lookups in this fashion, users are strongly discouraged from enabling it.
Users who cannot upgrade to 2.15.0 can mitigate the exposure by:
a) Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as a command line option or add log4j.formatMsgNoLookups=true to a log4j2.component.properties file on the classpath to prevent lookups in log event messages.
b) Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event messages.
c) Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the JndiContextSelector and JMSAppender to no longer function.
Reference:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
CVE-2021-45046
Severity: Medium
Vendor:
Apache Software Foundation
Versions Affected:
GridGain Community Edition 8.7.40 and earlier, 8.8.11 and earlier
GridGain Enterprise Edition 8.7.40 and earlier, 8.8.11 and earlier
GridGain Ultimate Edition 8.7.40 and earlier, 8.8.11 and earlier
Impact:
Apache Log4j2 Thread Context Message Pattern and Context Lookup Pattern vulnerable to a denial of service attack
Description:
It was found that the fix addressing CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete for certain non-default configurations. This could allow attackers with the control over Thread Context Map (MDC) input data, and when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using an JNDI Lookup pattern resulting in a denial of service (DOS) attack. Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default. Note that previous mitigations involving configuration changes such as to set the system property `log4j2.noFormatMsgLookup` to `true` do NOT mitigate this specific vulnerability. Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default. This issue can be mitigated in prior releases (<2.16.0) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).
Mitigation:
Current mitigation options are limited to 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.16.0. The cluster must be restarted after implementing the chosen option.
Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.
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
Reference:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046
CVE-2021-45046
Severity: Medium
Vendor:
Apache Software Foundation
Versions Affected:
GridGain Control Center 2021.08.01 and earlier.
Impact:
Apache Log4j2 Thread Context Message Pattern and Context Lookup Pattern vulnerable to a denial of service attack
Description:
It was found that the fix addressing CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete for certain non-default configurations. This could allow attackers with the control over Thread Context Map (MDC) input data, and when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using an JNDI Lookup pattern resulting in a denial of service (DOS) attack. Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default. Note that previous mitigations involving configuration changes such as to set the system property `log4j2.noFormatMsgLookup` to `true` do NOT mitigate this specific vulnerability. Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default. This issue can be mitigated in prior releases (<2.16.0) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).
Mitigation:
Current mitigation options are limited to 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.16.0. The GridGain Control Center must be restarted after implementing the chosen option.
Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.
The following script could be used to clean vulnerable jars:
# Go to GGCC installation directory
cd $CC_INSTALL_DIR
# 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 Control Center installation
Reference:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046
Denis Magda
The topic is used for security updates announcements and vulnerabilities disclosure.
1 person likes this