Data Platform mitigation for Apache Log4j 1.2 vulnerability CVE-2021-4104

[Mike_Marino]

Summary

A vulnerability has been publicly disclosed in Apache Log4j 1.2. The vulnerability has been assigned the identifier CVE-2021-4104 with a CVSS score of “High”.

All versions of Data Platform include Log4j 1.2 components, and thus are potentially exposed to this vulnerability. This article describes the potential impact of the vulnerability on Data Platform and options for mitigation.

Vulnerability description

The National Vulnerability Database describes the CVE-2021-4104 vulnerability at https://nvd.nist.gov/vuln/detail/CVE-2021-4104 as follows (current as of Dec 30, 2021):

JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration. 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. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default.

The default configuration of Data Platform does not meet the preconditions described for the vulnerability to be exploited.

Mitigation options

The following steps should be taken on all computers on which Data Platform components are installed:

• The following mitigation advised by Apache is appropriate to follow:
  
  

  Audit your logging configuration to ensure it has no JMSAppender configured.

  Logging configuration is stored in files named log4j.xml. Such configuration would be highly unusual for a Data Platform installation, and would only appear if a non-default configuration has been applied.

• Ensure appropriate access controls are in place to ensure only authorized users have access to computers. (This is appropriate to do regardless of the impact from Log4j vulnerabilities.)
  
  
• Upgrade to the Data Platform 5.5.48 release (or later). Out of an abundance of caution, Flexera has upgraded some of the Log4j components in this release of Data Platform to version 2.17.0 that is not exposed to currently disclosed vulnerabilities.

Steps to upgrade Data Platform

Perform the following steps to upgrade to the latest version of Data Platform. This is the typical upgrade process used for regular monthly releases, as documented in the Data Platform Release Notes.

1. Verify that a notice indicating a new Patch Set is now available is shown in the Data Platform Admin Console after a catalog sync.
   
   
   
   
2. Click the Details link to invoke the Patch Set deployment dialog. Ensure the Patch Set version shown is 5.5.48 (or newer).
   
   
   
   
3. Click the APPLY button to start the Patch Set installation.
   
   
   
   
4. Patch Set installation typically takes around 15 minutes. You may see an authentication dialog appear due to services restarting, which is normal. In this case, close your browser window, wait 10-15 minutes, then try logging back into the Admin Console.
   
   
5. The New Patch Set Available banner will no longer be displayed when installation is completed.

Related information

Also see the following pages:

• CVE definition: https://nvd.nist.gov/vuln/detail/CVE-2021-4104
• Expanded CVE definition: https://www.cve.org/CVERecord?id=CVE-2021-4104
• Apache Log4j Security Vulnerabilities page: https://logging.apache.org/log4j/2.x/security.html

Changelog

2021-12-30 12:53 PM CST: Initial article.

2022-01-03 7:50 PM CST: Add link to Data Platform 5.5.48 release notification.

2022-02-01 11:20 PM CST: Update to clarify that not all instances of the Log4j component have been updated in the Data Platform 5.5.48 release.

[scott_alexande]

My organization runs Data Platform on an isolated network that does not have internet access. What is the process to install the patch or otherwise upgrade to 5.5.48 for an offline network? 

[Mike_Marino]

@scott_alexande - This is possible by following the "offline synchronization" steps described on page 25 of the Data Platform Administrator Guide: https://docs.flexera.com/dataplatform55/Data_Platform_Administrator_Guide_5.5_e.pdf

[TeriStevenson]

Are there plans to upgrade to log4j 2.17.1?  My cyber security organization considers CVE-2021-44228 a severity 4 vulnerability that must be patched in Data Platform by May 2022

[lkwinchester]

I came back to this thread to check about:

CVE-2021-44832 (this is a NEW vulnerability) 

I have been notified by my internal IT Security that the impacted file versions listed in the CVE exist on the UI servers in my environment. We just updated to 5.5.50 on 3/18/2022 and the version impacted is still showing three files:

log4j-1.2-api-2.17.0.jar

log4j-api-2.17.0.jar

log4j-core-2.17.0.jar

 at the following path: 

Program Files\BDNA\User Console\Solution\system\kettle\plugins\elasticsearch-bulk-insert-plugin\lib

At what point whould we expect a patch that will remediate this to the recommended version of 2.17.1? Or is the expected remediation to manually replace these files on the server vs. through console version update/patching?

[Resnofendri]

@TeriStevenson, @lkwinchester  

In general, every potential vulnerability needs to be seen in the specific product context, whether the product exposes a specific vulnerability and thus makes it reachable.

The only CVE identifier the Apache Log4j version 2.17.1 fixes compared to the 2.17.0 release is CVE-2021-44832 (see [1]). This issue referenced by the CVE identifier CVE-2021-44832 requires that a potential attacker is able to construct a malicious Log4j configuration (details also in [1]). In the default configuration of our deployment this exposure is not the case.

To become theoretically exploitable, after deployment someone needs to alter the configuration directly (“with permission to modify the logging configuration file” [1]) or potentially alter it through a Man-in-the-Middle (MitM) scenario in case a configuration is loaded remotely. However, for both points to be reachable, security best practices need to be severely violated as in the first case only trusted personnel should be able to alter such configurations (such persons can typically already execute arbitrary code anyway) and in the latter case any remote loading of a configuration has to be properly protected from tampering and thus the MitM path becomes ineffective.

In essence, the 2.17.0 version is already properly protecting the deployed product when compared to the 2.17.1 version as there is seemingly no valid exploitation scenario for CVE-2021-44832 exposed in our case.

With that said, we understand that some of our customers have certain security requirements that require further patching. We're investigating the effort to upgrade the log4j components in Data Platform to version 2.17.1 or later in one of the future Data Platform releases. We'll update this blog post when we have more clarity in terms of expected timeline and additional details.

Reference:

[1] https://logging.apache.org/log4j/2.x/security.html

[joshua_neadow]

Are there any updates on this?  we are getting CVE-2021-44832 for 2.17.0 as well.  I see this discussion occurred back in April and new releases are coming out monthly.  Please update

[ChrisG]

The following Data Platform patch includes an update to Pentaho Business Intelligence which in turn includes an update to Log4J 2.17.1: Data Platform 2022 - 5.5.54 Patch (June 2022)