Description from CVE
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".
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, and not all versions before 2.15.0 as the GitHub advisory states. The 1.x branch is not affected by this vulnerability.
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.
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.
If upgrading is not possible, then ensure the -Dlog4j2.formatMsgNoLookups=true system property is set on both client- and server-side components.
Reference: https://github.com/advisories/GHSA-jfh8-c2jp-5v3q
Link https://nvd.nist.gov/vuln/detail/CVE-2021-44228
Description from CVE 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".
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, 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.
Mitigating Controls
For versions lower than 2.10.0: User can modify the log4j component to remove the JndiLookup.class to avoid JNDI lookups altogether. Reference: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990305306
Modifying lookup replacements to force external JNDI lookups to be disabled using the format string %m{nolookups} is also an option. Reference: https://issues.apache.org/jira/browse/LOG4J2-2109
For versions 2.10.0 and higher:
If upgrading is not possible, then ensure the -Dlog4j2.formatMsgNoLookups=true system property is set on both client- and server-side components. Reference: https://github.com/advisories/GHSA-jfh8-c2jp-5v3q
Root Cause loan-amortization-calculator-1.0.8-jar-with-dependencies.jarorg/apache/logging/log4j/core/lookup/JndiLookup.class[2.0.2, ) loan-amortization-calculator-1.0.8-jar-with-dependencies.jarorg/apache/logging/log4j/core/appender/mom/JmsAppender.class[2.13.1, ) loan-amortization-calculator-1.0.8-jar-with-dependencies.jarorg/apache/logging/log4j/core/net/JndiManager.class[2.13.1, ) Advisories Project:https://github.com/advisories/GHSA-jfh8-c2jp-5v3q Project:https://github.com/apache/logging-log4j2/pull/608 Project:https://issues.apache.org/jira/browse/LOG4J2-2109 Project:https://issues.apache.org/jira/browse/LOG4J2-3201 CVSS Details Sonatype CVSS 3:10.0 CVSS Vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H