search cancel

CVE-2021-44228: Log4j 2 Vulnerability and CA Productivity Accelerator

book

Article ID: 237615

calendar_today

Updated On:

Products

Training

Issue/Introduction

CA Productivity Accelerator Manager (server component) uses a version of Apache Log4j which has vulnerabilities CVE-2021-44228, CVE-2021-45046 and CVE-2021-45105.

Cause

CVE-2021-44228

The Apache Software Foundation has released a security advisory to address a remote code execution vulnerability (CVE-2021-44228) affecting Log4j versions 2.0-beta9 to 2.14.1. A remote attacker could exploit this vulnerability to take control of an affected system. Log4j is an open-source, Java-based logging utility widely used by enterprise applications and cloud services.

10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)

CVE-2021-45046

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 allow attackers with control over Thread Context Map (MDC) input data 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 a JNDI Lookup pattern resulting in a denial of service (DOS) attack.

The original severity of this CVE was rated as Moderate; since this CVE was published security experts found additional exploits against the Log4j 2.15.0 release, that could lead to information leaks, RCE (remote code execution) and LCE (local code execution) attacks.

Base CVSS Score changed from 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L) to 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H).

CVE-2021-45105 

Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from uncontrolled recursion from self-referential lookups. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process. This is also known as a DOS (Denial of Service) attack. This issue was fixed in Log4j 2.17.0 and 2.12.3.

CVSS 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/E:U/RL:O/RC:C)

CVE-2021-44832

Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.

CVSS 6.6 (AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H)

Environment

CA Productivity Accelerator Manager 13.0, 13.1, 14.1, 14.3, 14.4, 14.5

Resolution

In this article, you can find a manual fix, but the best option is to upgrade your system to CA Productivity Accelerator 14.6. This new release has replaced the used Log4J 2.14 version with the newest Log4J 2.17.1 version. The 14.6 release is already available on the Broadcom Support Portal (https://support.broadcom.com/group/ecx/productdownloads?subfamily=TRAINING) for our customers.

Manual Workaround

  • For CVE-2021-44228: 

To prevent exploiting the CVE-2021-44228 vulnerability please do the following:

    1. Go to TOMCAT\bin folder
    2. Execute TomcatXw.exe
    3. Go to Java tab
    4. Enter “-Dlog4j2.formatMsgNoLookups=true” to the Java options
    5. Restart the Tomcat

  • For CVE-2021-45046:Log4j 2.x CA Productivity Accelerator Manager customers using the default Pattern Layout for logging are safe.
    Only in cases where a customer uses a non-default Pattern Layout, he might become affected.

    Mitigation:
    • Remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

  • For CVE-2021-45105: CA Productivity Accelerator Manager customers using the default Pattern Layout for logging are safe.
    Only in cases where a customer uses a non-default Pattern Layout, he might become affected.

    Mitigation:
    • Remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class