LUMADA

Customer Portal

Introducing Lumada DataOps Suite

Innovate with Data: Lumada simplifies data management with automation and collaboration.

With Lumada, you can: Gain 360-degree views of your customers, products and assets.

Streamline your business operations and take out cost, and meet stringent compliance demands.

log4j 1 and log4j 2 vulnerabilities found in CVE-2021-4104, CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, and CVE-2021-44832

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

 

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


Lumada Software

Pentaho Software

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.  
    (NotePentaho 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 
    (NoteThese 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. 

  1. activemq-all-5.15.11.jar (default location \pentaho-server\pentaho-solutions\system\kettle\plugins\pdi-jms-plugin\lib) 
  2.  log4j jar 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/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.  

  

  1. pentaho-server\pentaho-solutions\system\karaf\system\org\ops4j\pax\logging\pax-logging-log4j2\1.10.2\pax-logging-log4j2-1.10.2.jar  
  2. 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.

 


 

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

Follow the mitigation recommendation from Apache (News section) for setting the following environment variable to be true in the profile of LDC service user and restart app-server, metadata-server and agent

For e.g.:
export LOG4J_FORMAT_MSG_NO_LOOKUPS = true
echo $LOG4J_FORMAT_MSG_NO_LOOKUPS
• Also, remove the 1.2.17 libraries from the following locations of the deployment:
<ldc-install-dir>/app-server/lib/dependencies/log4j-1.2.17.jar
<ldc-install-dir>/app-server/lib/dependencies/slf4j-log4j12-1.7.25.jar
• As always please, review your Firewall/Network fencing setup and make sure your network settings are configured so that only trusted traffic is sent to the Data Catalog’s Application Server

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

This vulnerability requires that the vulnerable class be removed from log4j-core-*.jar file. 

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. There are three locations this jar file can be found. 

 

  • /opt/ldc/metadata-server/lib/logging/
  • /opt/ldc/agent/lib/logging/
  • /opt/ldc/app-server/lib/logging

 

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

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

 


We always recommend updating to the latest/supported version with the latest Service Pack of any Hitachi Vantara released software. This will ensure the latest updates, which often contain fixes to potential threats, are installed.  

If you have any questions, please open a ticket with our Support Team using the Support Portal at http://support.hitachivantara.com/   

 

 

Comments