Catch vulnerabilities in your projects, automatically on every pull request. Try Sonatype Lift for free. Install Lift

Vulnerability

CVE-2021-44228
CVSS Score 10.0 Critical

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Changed

Confidentiality Impact

High

Integrity Impact

High

Availability Impact

High

CVSS Vector

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

CWE

Not Recorded

Description

[CVE-2021-44228] Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and pa...

Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. 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. From log4j 2.15.0, this behavior has been disabled by default. In previous releases (>2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to "true" or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false". =================================================== The following information is provided by Sonatype Nexus Intelligence. Nexus Intelligence is the only security research service that performs "secondary expansion" to determine if newly discovered vulnerabilities are also present in other components. Learn more about Nexus Intelligence -- https://www.sonatype.com/products/intelligence =================================================== Explanation --------------------------------------------------- The `log4j-core` package is vulnerable to Deserialization of Untrusted data. The vulnerable methods allow the `JNDI` Java interface to be used to request resources from arbitrary URIs using the `LDAP` and `LDAPS` protocols. This leads to Java objects contained within the resource to be deserialized and processed. Applications that use the `log4j-core` library to log events and utilize application data in log messages may inadvertently allow user input to be included inside their log messages. Remote attackers can leverage this behavior to fetch a malicious resource under their control. This would lead to malicious Java code being deserialized and executed in the context of the vulnerable application and may lead to Remote Code Execution (RCE). *Advisory Deviation Notice:* The Sonatype security research team discovered that the root cause of the vulnerability is in `org.apache.logging.log4j:log4j-core`, and is not in `org.apache.logging.log4j:log4j-api` as the GitHub advisory states. The research team has also discovered that the vulnerable code was introduced in version 2.0-beta9 up to 2.12.2, and 2.13.0 up to 2.15.0, and not all versions before 2.15.0 as the GitHub advisory states. The 1.x branch is not affected by this vulnerability. *Vulnerable File(s) and Function(s)*: org/apache/logging/log4j/core/net/JndiManager.class * lookup() org/apache/logging/log4j/core/lookup/JndiLookup.class * lookup() org/apache/logging/log4j/core/appender/mom/JmsAppender$Builder.class * build() Detection --------------------------------------------------- The application is vulnerable by using this component and including formatted message substitutions in their application's logged messages where formatted message lookups are enabled. Note that this is the default behavior in all versions prior to 2.15.0. Reference: https://github.com/advisories/GHSA-jfh8-c2jp-5v3q Recommendation --------------------------------------------------- We recommend upgrading to a version of this component that is not vulnerable to this specific issue. Note: If this component is included as a bundled/transitive dependency of another component, there may not be an upgrade path. In this instance, we recommend contacting the maintainers who included the vulnerable package. Alternatively, we recommend investigating alternative components or a potential mitigating control. **Project Recommendations** * Java 8 (or later) users should upgrade to release 2.16.0. * Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available (work in progress, expected to be available soon). * Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class Reference: https://logging.apache.org/log4j/2.x/security.html

Sign in and get help with:

  • Vulnerability details for your components
  • Affected components
  • Affected versions