Summary:

Hitachi Vantara is aware of the aforementioned vulnerabilities along with the community. Any changes to the mitigation strategy listed below will be updated in this article. Please check back periodically to ensure you have the latest information.

CVE-2021-4104 – The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228. This issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default.
Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-4104

CVE-2021-44228 – This issue only effects log4j version 2.14.1 and below. 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.
Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-44228

CVE-2021-45046 – This issue only effects log4j version 2.15 and below. It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout
Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046

CVE-2021-45105 – Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3 and 2.3.1) did not protect from uncontrolled recursion from self-referential lookups. This allows an attacker with control over Thread Context Map data to cause a denial of service when a crafted string is interpreted.
Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105

CVE-2021-44832 – Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3 and 2.3.1) did not protect from uncontrolled recursion from self-referential lookups. This allows an attacker with control over Thread Context Map data to cause a denial of service when a crafted string is interpreted.
Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832

CVE-2021-42392 – The org.h2.util.JdbcUtils.getConnection method of the H2 database takes as parameters the class name of the driver and URL of the database. An attacker may pass a JNDI driver name and a URL leading to a LDAP or RMI servers, causing remote code execution. This can be exploited through various attack vectors, most notably through the H2 Console which leads to unauthenticated remote code execution.
Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-42392

CVE-2022-23302 – JMSSink in all versions of Log4j 1.x is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration or if the configuration references an LDAP service the attacker has access to. The attacker can provide a TopicConnectionFactoryBindingName configuration causing JMSSink to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-4104
Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23302

CVE-2022-23305 – By design, the JDBCAppender in Log4j 1.2.x accepts an SQL statement as a configuration parameter where the values to be inserted are converters from PatternLayout. The message converter, %m, is likely to always be included. This allows attackers to manipulate the SQL by entering crafted strings into input fields or headers of an application that are logged allowing unintended SQL queries to be executed. Note this issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is not the default.
Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23305

CVE-2022-23307 – CVE-2020-9493 identified a deserialization issue that was present in Apache Chainsaw. Prior to Chainsaw V2.0 Chainsaw was a component of Apache Log4j 1.2.x where the same issue exists.
Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23307

Mitigation by product:
Pentaho Software
CVE-2021-4104 Mitigation
CVE-2021-44228 Mitigation
CVE-2021-45046 Mitigation
CVE-2021-45105 Mitigation
CVE-2021-44832 Mitigation
CVE-2021-42392 Mitigation
CVE-2022-23302 Mitigation
CVE-2022-23305 Mitigation
CVE-2022-23307 Mitigation

Worker Nodes
CVE-2021-4104 Mitigation
CVE-2021-44228 Mitigation
CVE-2021-45046 Mitigation
CVE-2021-45105 Mitigation
CVE-2021-44832 Mitigation
CVE-2021-42392 Mitigation
CVE-2022-23302 Mitigation
CVE-2022-23305 Mitigation
CVE-2022-23307 Mitigation

Lumada Software

LDC
CVE-2021-4104 Mitigation
CVE-2021-44228 Mitigation
CVE-2021-45046 Mitigation
CVE-2021-45105 Mitigation
CVE-2021-44832 Mitigation
CVE-2021-42392 Mitigation
CVE-2022-23302 Mitigation
CVE-2022-23305 Mitigation
CVE-2022-23307 Mitigation
LEI
CVE-2021-4104 Mitigation
CVE-2021-44228 Mitigation
CVE-2021-45046 Mitigation
CVE-2021-45105 Mitigation
CVE-2021-44832 Mitigation
CVE-2021-42392 Mitigation
CVE-2022-23302 Mitigation
CVE-2022-23305 Mitigation
CVE-2022-23307 Mitigation
LDOS
CVE-2021-4104 Mitigation
CVE-2021-44228 Mitigation
CVE-2021-45046 Mitigation
CVE-2021-45105 Mitigation
CVE-2021-44832 Mitigation
CVE-2021-42392 Mitigation
CVE-2022-23302 Mitigation
CVE-2022-23305 Mitigation
CVE-2022-23307 Mitigation

Pentaho Software

As of February 28, 2022 the vulnerabilities mentioned in this article are resolved in Pentaho Service Packs 8.3.0.26 and 9.2.0.3. These service packs will upgrade Pentaho to use Log4j version 2.17.1 for its logging. The manual steps in this article are provided for customers using Pentaho versions prior to these Service Packs versions. If you are not able to upgrade to Pentaho 8.3.0.26 or 9.2.0.3, then you may need to follow the manual mitigation steps below.

CVE-2021-4104 Mitigation for Pentaho

This vulnerability is not present in our current fully supported Pentaho versions as we do not use the classes that are vulnerable by default.

However, in response to the recently published CVE-2021-44228, Hitachi Vantara’s Engineering Teams have performed extensive testing on our released software, including Pentaho. 

For the Pentaho use-case, the vulnerability would only present itself if: 

Java 8u120 or older is in use.
(Note: Pentaho software has supported Java 8u251 since v8.3.) 
You have set the following java system properties to true
com.sun.jndi.rmi.object.trustURLCodebase
com.sun.jndi.cosnaming.object.trustURLCodebase
(Note: These properties are set to false by default in Java 8u121 and above)
JmsAppender is in-use
(Note: Pentaho does not use JMSAppender, however that does not prevent adding it to the log4j properties to enable it)

In the above scenarios these items can be enable by changing the settings or customizing to use JMSAppender.

To be sure that the vulnerable classes are not available for use, you may run the following commands against the jar files that contain the JMSAppender class.

activemq-all-5.15.11.jar (default location \pentaho-server\pentaho-solutions\system\kettle\plugins\pdi-jms-plugin\lib)
log4j jar file located in the following locations:

Please Note: The above files may appear in other directories depending on your version of Pentaho.

zip -q -d activemq-all-5.* "org/apache/log4j/net/JMSAppender.class"
zip -q -d log4j-1.2.* "org/apache/log4j/net/JMSAppender.class"
Note: The above command will need to be run on all the locations where the log4j jar file exists.

If using 7-zip the commands would be:

7z d activemq-all-5.* "org/apache/log4j/net/JMSAppender.class"
7z d log4j-1.2.* "org/apache/log4j/net/JMSAppender.class"
Note: The above command will need to be run on all the locations where the log4j jar file exists.

To verify that the JMSAppender.class is not present, open the jar files in the above commands with any zip utility and drill to \org\apache\log4j\net\ and check if the JMSApennder.class is still present. If it is not there then the command was successful and the JMSAppender class can no longer be called.

CVE-2021-44228 Mitigation for Pentaho

The vulnerable class is not present in log4j version 1.2, however, one of the plugins does have the class present even though it in not used. This class does not exist in 8.3 and before.

To be sure that the vulnerable classes are not available for use, you may run the following commands against the jar files that contain the JndiLookup class.
Note: Location number 2 will require you to first decompress the pentaho-mapreduce-libraries.zip parent archive and recreate it with the modified pax-logging-log4j2 inside.

pentaho-server\pentaho-solutions\system\karaf\system\org\ops4j\pax\logging\pax-logging-log4j2\1.10.2\pax-logging-log4j2-1.10.2.jar
pentaho-server\pentaho-solutions\system\kettle\plugins\pentaho-big-data-plugin\pentaho-mapreduce-libraries.zip\system\karaf\system\org\ops4j\pax\logging\pax-logging-log4j2\1.10.2\pax-logging-log4j2-1.10.2.jar

zip -d -q pax-logging-log4j2-1.10.2.jar "org/apache/logging/log4j/core/lookup/JndiLookup.class"

If using 7zip the commands would be:

7z d pax-logging-log4j2-1.10.2.jar "org/apache/logging/log4j/core/lookup/JndiLookup.class"

To verify that the JndiLookup is not present, open the jar files in the above commands with any zip utility and drill to \org\apache\logging\log4j\core\lookup\ and check if the JndiLookup.class is still present. If it is not there then the command was successful and the JndiLookup class can no longer be called.

CVE-2021-45056 Mitigation for Pentaho

The mitigation steps for this vulnerability are the same as for CVE-2021-44228. If you have applied those steps then this vulnerability does not exist.

CVE-2021-45105 Mitigation for Pentaho

This issue does not effect Pentaho as we do not use the log4jv2. This issue only effects Apache Log4j2 versions 2.0-alpha1 through 2.16.0

CVE-2021-44832 Mitigation for Pentaho

This issue does not effect Pentaho as we do not use the classes by default. The above CVEs mitigation steps will cover removing the classes completely.

CVE-2021-42392 Mitigation for Pentaho

This issue effects only the sample data connection which by default should not be used in production. To immediately address the vulnerability, you can remove the H2 driver and disable the SampleData databases.

Note: Please be advised that this is only recommended if you do not use any H2 connections in your production environment.

Remove the sample data from Pentaho

Pentaho 9.2:
https://help.hitachivantara.com/Documentation/Pentaho/9.2/Setup/Manage_the_Pentaho_Server#Remove_sample_data_from_the_Pentaho_Server

Pentaho 8.3:
https://help.hitachivantara.com/Documentation/Pentaho/8.3/Setup/Manage_the_Pentaho_Server#Remove_sample_data_from_the_Pentaho_Server

Delete the H2 driver from the following locations:

/server/pentaho-server/tomcat/lib/h2-1.x.xxx.jar
/server/pentaho-server/tomcat/webapps/pentaho/WEB-INF/lib/h2-1.x.xxx.jar

/client-tools/data-integration/lib/h2-1.x.xxx.jar
/client-tools/metadata-editor/libext/JDBC/h2-1.x.xxx.jar
/client-tools/report-designer/lib/jdbc/h2-1.x.xxx.jar

CVE-2022-23302 Mitigation for Pentaho

By default Pentaho does not use the class JMSSink. To be sure that the vulnerable classes are not available for use, you may run the following commands against the jar files that contain the JMSSink class

Delete the log4j jar under big-data-plugin. The jar can be found in the following folders

design-tools\data-integration\plugins\pentaho-big-data-plugin\hadoop-configurations\emr511\lib\client\log4j-1.2.17.jar
design-tools\data-integration\plugins\pentaho-big-data-plugin\hadoop-configurations\hdp30\lib\client\log4j-1.2.17.jar
design-tools\data-integration\plugins\pentaho-big-data-plugin\hadoop-configurations\hdp30\lib\client\log4j-1.2.17.jar
design-tools\metadata-editor\plugins\pentaho-big-data-plugin\hadoop-configurations\emr511\lib\client\log4j-1.2.17.jar
design-tools\metadata-editor\plugins\pentaho-big-data-plugin\hadoop-configurations\hdp30\lib\client\log4j-1.2.17.jar
design-tools\report-designer\plugins\pentaho-big-data-plugin\hadoop-configurations\emr511\lib\client\log4j-1.2.17.jar
design-tools\report-designer\plugins\pentaho-big-data-plugin\hadoop-configurations\hdp30\lib\client\log4j-1.2.17.jar

Delete pax-logging-service bundle. It can be located in the following locations

\pentaho-server\pentaho-solutions\system\karaf\system\org\ops4j\pax\logging\pax-logging-service

\design-tools\data-integration\system\karaf\system\org\ops4j\pax\logging\pax-logging-service

\design-tools\metadata-editor\system\karaf\system\org\ops4j\pax\logging\pax-logging-service

Scrub the activemq-all-5.15.11 component. The activemq-all-5.15.11.jar located in the following locations:
\pentaho-server\pentaho-solutions\system\kettle\plugins\pdi-jms-plugin\lib\activemq-all-5.15.11.jar
\design-tools\data-integration\plugins\pdi-jms-plugin\lib\activemq-all-5.15.11.jar
\design-tools\metadata-editor\plugins\pdi-jms-plugin\lib\activemq-all-5.15.11.jar
\design-tools\report-designer\plugins\pdi-jms-plugin\lib\activemq-all-5.15.11.jar
Scrub log4j jar. The file located in the following locations:
\design-tools\aggregation-designer\lib\log4j-1.2.xx.jar
\design-tools\data-integration\lib\log4j-1.2.xx.jar
\design-tools\data-integration\jdbc-distribution\lib\log4j-1.2.xx.jar
\design-tools\metadata-editor\libext\pentaho\log4j-1.2.xx.jar
\design-tools\report-designer\lib\log4j-1.2.xx.jar
\design-tools\report-designer\jdbc-distribution\lib\log4j-1.2.xx.jar
\jdbc-distribution\lib\log4j-1.2.xx.jar
\license-installer\lib\log4j-1.2.xx.jar
\pentaho-server\tomcat\webapps\pentaho\WEB-INF\lib\log4j-1.2.xx.jar

Please Note: The above files may appear in other directories depending on your version of Pentaho.

zip -q -d activemq-all-5.* "org/apache/log4j/net/JMSSink.class"
zip -q -d log4j-1.2.* "org/apache/log4j/net/JMSSink.class"
Note: The above command will need to be run on all the locations where the log4j jar file exists.

If using 7-zip the commands would be:

7z d activemq-all-5.* "org/apache/log4j/net/JMSSink.class"
7z d log4j-1.2.* "org/apache/log4j/net/JMSSink.class"
Note: The above command will need to be run on all the locations where the log4j jar file exists.

To verify that the JMSSink.class is not present, open the jar files in the above commands with any zip utility and drill to \org\apache\log4j\net\ and check if the JMSSink.class is still present. If it is not there then the command was successful and the JMSSink class can no longer be called.

CVE-2022-23305 Mitigation for Pentaho

By default Pentaho does not use the JDBCAppender class. To be sure that the vulnerable classes are not available for use, you may run the following commands against the jar files that contain the JDBCAppender class.

Scrub log4j jar. The file located in the following locations:
\design-tools\aggregation-designer\lib\log4j-1.2.xx.jar
\design-tools\data-integration\lib\log4j-1.2.xx.jar
\design-tools\data-integration\jdbc-distribution\lib\log4j-1.2.xx.jar
\design-tools\metadata-editor\libext\pentaho\log4j-1.2.xx.jar
\design-tools\report-designer\lib\log4j-1.2.xx.jar

\design-tools\report-designer\jdbc-distribution\lib\log4j-1.2.xx.jar
\jdbc-distribution\lib\log4j-1.2.xx.jar
\license-installer\lib\log4j-1.2.xx.jar
\pentaho-server\tomcat\webapps\pentaho\WEB-INF\lib\log4j-1.2.xx.jar

Please Note: The above files may appear in other directories depending on your version of Pentaho.

zip -q -d activemq-all-5.* "org/apache/log4j/jdbc/JDBCAppender.class"
zip -q -d log4j-1.2.* "org/apache/log4j/jdbc/JDBCAppender.class"
Note: The above command will need to be run on all the locations where the log4j jar file exists.

If using 7-zip the commands would be:

7z d activemq-all-5.* "org/apache/log4j/jdbc/JDBCAppender.class"
7z d log4j-1.2.* org/apache/log4j/jdbc/JDBCAppender.class"
Note: The above command will need to be run on all the locations where the log4j jar file exists.

To verify that the JDBCAppender component is not present, open the jar files in the above commands with any zip utility and drill to \org\apache\log4j\jdbc\ and check if the JDBCAppender.class is still present. If it is not there then the command was successful and the JDBCAppender.class can no longer be called.

CVE-2022-23307 Mitigation for Pentaho

By default Pentaho does not use any of the chainsaw classes. To be sure that the vulnerable classes are not available for use, you may run the following commands against the jar files that contain the chainsaw component.

Delete the log4j jar under big-data-plugin. The jar can be found in the following folders

design-tools\data-integration\plugins\pentaho-big-data-plugin\hadoop-configurations\emr511\lib\client\log4j-1.2.17.jar
design-tools\data-integration\plugins\pentaho-big-data-plugin\hadoop-configurations\hdp30\lib\client\log4j-1.2.17.jar
design-tools\data-integration\plugins\pentaho-big-data-plugin\hadoop-configurations\hdp30\lib\client\log4j-1.2.17.jar
design-tools\metadata-editor\plugins\pentaho-big-data-plugin\hadoop-configurations\emr511\lib\client\log4j-1.2.17.jar
design-tools\metadata-editor\plugins\pentaho-big-data-plugin\hadoop-configurations\hdp30\lib\client\log4j-1.2.17.jar
design-tools\report-designer\plugins\pentaho-big-data-plugin\hadoop-configurations\emr511\lib\client\log4j-1.2.17.jar
design-tools\report-designer\plugins\pentaho-big-data-plugin\hadoop-configurations\hdp30\lib\client\log4j-1.2.17.jar

Delete pax-logging-service bundle. It can be located in the following locations****

\pentaho-server\pentaho-solutions\system\karaf\system\org\ops4j\pax\logging\pax-logging-service

\design-tools\data-integration\system\karaf\system\org\ops4j\pax\logging\pax-logging-service

\design-tools\metadata-editor\system\karaf\system\org\ops4j\pax\logging\pax-logging-service

Please Note: The above files may appear in other directories depending on your version of Pentaho.

zip -q -d activemq-all-5.* org/apache/log4j/chainsaw/*
zip -q -d log4j-1.2.* org/apache/log4j/chainsaw/*
Note: The above command will need to be run on all the locations where the log4j jar file exists.

If using 7-zip the commands would be:

7z d activemq-all-5.* org/apache/log4j/chainsaw/*
7z d log4j-1.2.* org/apache/log4j/chainsaw/*
Note: The above command will need to be run on all the locations where the log4j jar file exists.

To verify that the chainsaw component is not present, open the jar files in the above commands with any zip utility and drill to \org\apache\log4j\chainsaw\ and check if the chainsaw is still present. If it is not there then the command was successful and the chainsaw component can no longer be called.

Worker Nodes

CVE-2021-4104 Mitigation for Worker Nodes

This issue does not effect Worker Nodes as JMS Appender is not used.

CVE-2021-44228 Mitigation for Worker Nodes

A patch was provided by Hitachi Vantara to address this vulnerability.

CVE-2021-45046 Mitigation for Worker Nodes

A patch was provided by Hitachi Vantara to address this vulnerability.

CVE-2021-45105 Mitigation for Worker Nodes

Logstash and Elastic with the logging configuration shipped do not use ${ctx: lookups that are exploitable.

CVE-2021-44832 Mitigation for Worker Nodes

Logstash and Elastic with the logging configuration shipped do not use the JDBC Appender that is exploitable.

Per our posted End of Life Policy, v8.3.x and v9.2.x are currently fully supported.  

Lumada Software

Lumada Data Catalog

CVE-2021-4104 Mitigation for LDC

Patch below for CVE-2021-45105 resolves this vulnerability.

CVE-2021-44228 Mitigation for LDC

Patch below for CVE-2021-45105 resolves this vulnerability.

CVE-2021-45046 Mitigation for LDC

Patch below for CVE-2021-45105 resolves this vulnerability.

CVE-2021-45105 Resolution for LDC

This vulnerability hotfix addresses the mitigation and resolution for the vulnerability identified on Apache log4j component that is used in Lumada Data Catalog release 6.1.1, 6.0.1, and 2019.3. This hotfix addresses the previously detected vulnerabilities for Apache log4j including CVE-2021-4104, CVE-2021-44228, CVE-2021-45046, and CVE-2021-45105.

To resolve the vulnerability please follow the steps in the attached file Lumada-Data-Catalog-Vuln-Hotfix-CVE-2021-45105-Readme.pdf using the tar file cve-2021-45105-log4j-HF.tar

CVE-2021-44832 Mitigation for LDC

Patch above for CVE-2021-45105 resolves this vulnerability.

Lumada Edge Intelligence

CVE-2021-4104 Mitigation for LEI

The LEI team has determined that this vulnerability does not affect this software as JNDI remote code execution is disabled.

CVE-2021-44228 Mitigation for LEI

The LEI team has determined that this vulnerability does not affect this software as JNDI remote code execution is disabled

CVE-2021-45046 Mitigation for LEI

The LEI team has determined that this vulnerability does not affect this software as JNDI remote code execution is disabled

CVE-2021-45105 Mitigation for LEI

The LEI team has determined that this vulnerability does not affect this software as JNDI remote code execution is disabled

CVE-2021-44832 Mitigation for LEI

The LEI team has determined that this vulnerability does not affect this software as JNDI remote code execution is disabled