ArtyomPanfutov / loan-amortization-calculator

A light-weight library that allows calculating annual loan amortization schedule with a capability of setting early (additional) payments.
MIT License
11 stars 5 forks source link

Code throwing CVE-2021-44228 vulnerability #41

Open gauravdeshmukh612 opened 2 years ago

gauravdeshmukh612 commented 2 years ago

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

ArtyomPanfutov commented 2 years ago

Thank you! I'm planning a migration to slf4j right now. So won't be a problem soon.