SBN

CyRC Vulnerability Analysis: Remote code execution zero-day exploit in Java logging library (log4j)

The NVD currently lacks a CVSS score for this vulnerability, but the Synopsys Cybersecurity Research Center (CyRC) has issued a corresponding Black Duck® Security Advisory (BDSA), and assigned a CVSS score of 9.1, with links to proof-of-concept exploits.

A dangerous, zero day exploit has been identified in log4j, a popular Java logging library

A dangerous, zero day exploit has been identified in log4j, a popular Java logging library.

Apache log4j/log4j2 is broadly used within the Java community to implement application logging. As log4j is a de facto standard within the Java community, it’s likely that most Java applications use it as their log interface.

The NVD has assigned CVE-2021-44228 to this vulnerability, which impacts Apache log4j2 versions from 2.0-beta9 to 2.14.1. In these versions, Java naming and directory interface (JNDI) features are not protected against attacker-controlled LDAP or JNDI endpoints. If message substitution is enabled, an attack can trigger remote code execution (RCE) for arbitrary code loaded from the attacker-controlled LDAP servers.

The NVD currently lacks a CVSS score for this vulnerability, but the Synopsys Cybersecurity Research Center (CyRC) has issued a corresponding Black Duck® Security Advisory (BDSA), and assigned a CVSS score of 9.1, with links to proof-of-concept exploits. This information enables users to quickly identify where they have exposure to this vulnerability without requiring any rescanning of their applications. This will simplify the triage, validation, and remediation efforts.

Excerpts from the BDSA record

Black Duck Security Advisory record

Apache log4j, as used in many popular services, is vulnerable to improperly allowing lightweight directory access protocol (LDAP) access via Java naming and directory interface (JNDI) features. A remote attacker that supplies the end application with specially crafted input that is then processed by the log4j subcomponent could cause the execution of arbitrary Java code.

How to fix it

Fixed in 2.15.0-rc2 by this commit and this commit.

The latest releases can be found here.

Workaround

A third party has proposed a workaround here. They suggest the following:

  • Version 2.10.0 and above have the log4j2.formatMsgNoLookups property that can be set to true to disable the affected functionality.
  • In versions below 2.10.0, every logging pattern layout should be modified to say %m{nolookups} instead of %m in the logging config files.

Further, as suggested here, Java versions higher than 6u211, 7u201, 8u191, and 11.0.1 protect against specific exploit techniques; however, code execution and other outcomes cannot be ruled out through other available techniques on these versions and specific environments.

It should also be possible to mitigate the issue by removing the JndiLookup class from the classpath.

How Synopsys helps

With Black Duck software composition analysis (SCA), all the open source used in your applications is identified, cataloged, and continuously monitored for newly disclosed vulnerabilities. Should a vulnerability be discovered, our team of security researchers works to compile, confirm, and augment any related information before issuing a security advisory to all affected customers. These advisories contain the details necessary to understand, prioritize, and remediate vulnerabilities within the context of your applications, and they’re issued within hours of a vulnerability being disclosed.

*** This is a Security Bloggers Network syndicated blog from Software Integrity Blog authored by Jagat Parekh. Read the original post at: https://www.synopsys.com/blogs/software-security/zero-day-exploit-log4j-analysis/

Secure Guardrails