CVE-2021–4104 CVE-2021–44228 CVE-2021–45046 Log4j 2 Vulnerability spring boot fix

The complete list of flaws discovered to date in the logging framework after the original remote code execution bug was disclosed is as follows —

• CVE-2021–44228 (CVSS score: 10.0) — A remote code execution vulnerability affecting Log4j versions from 2.0-beta9 to 2.14.1 (Fixed in version 2.15.0)
• CVE-2021–45046 (CVSS score: 9.0) — An information leak and remote code execution vulnerability affecting Log4j versions from 2.0-beta9 to 2.15.0, excluding 2.12.2 (Fixed in version 2.16.0)
• CVE-2021–45105 (CVSS score: 7.5) — A denial-of-service vulnerability affecting Log4j versions from 2.0-beta9 to 2.16.0 (Fixed in version 2.17.0)
• CVE-2021–4104 (CVSS score: 8.1) — An untrusted deserialization flaw affecting Log4j version 1.2 (No fix available; Upgrade to version 2.17.1)

The second vulnerability — tracked as CVE-2021–45046 — is rated 3.7 out of a maximum of 10 on the CVSS rating system and affects all versions of Log4j from 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0, which the project maintainers shipped last week to address a critical remote code execution vulnerability (CVE-2021–44228) that could be abused to infiltrate and take over systems.

The vulnerability has been reported with CVE-2021–44228 against the log4j-core jar and has been fixed in Log4J v2.16.0. CVE-2021–44228 is a vulnerability classified under the highest severity mark, i.e. 10 out of 10. It allows an attacker to execute arbitrary code by injecting attacker-controlled data into a logged message. As far as vulnerabilities are concerned, CVE-2021–44228 is probably as bad as it gets.

JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has, write access to the Log4j configuration. It is rated 8.2 on CVSS rating system. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021–44228. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default. Apache Log4j 1.2 reached the end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.

Maven

For Maven users, you can follow these instructions and set the log4j2.version property.

For example:

<properties>
    <log4j2.version>2.17.1</log4j2.version>
</properties>

To check that the override has been applied run ./mvnw dependency:list | grep log4j or for windows ./mvn dependency:list | FIND "log4j" and check that the version is 2.17.1.

Gradle

For Gradle users, you can follow these instructions and update the version property, import the BOM or use aresolutionStrategy.

For most users, setting the log4j2.version property will be sufficient:

ext['log4j2.version'] = '2.17.1'
COPY

If you’re using Gradle’s platform support instead of our dependency management plugin then you can add a dependency to the Log4J BOM:

implementation(platform("org.apache.logging.log4j:log4j-bom:2.17.1"))
COPY

And if you can’t use either of those methods then you can declare a resolutionStrategy:

configurations.all {
	resolutionStrategy.eachDependency { DependencyResolveDetails details ->
		if (details.requested.group == 'org.apache.logging.log4j') {
			details.useVersion '2.17.0'
		}
	}
}
		if (details.requested.group == 'org.apache.logging.log4j') {
			details.useVersion '2.17.0'
		}
	}
}

Whichever method you choose, to check that the override has been applied you can run ./gradlew dependencyInsight --dependency log4j-core and look for version 2.17.0.

Other Options

For users that can’t upgrade, another option is to set thelog4j2.formatMsgNoLookups system property to true. For example, you can start your app using java -Dlog4j2.formatMsgNoLookups=true -jar myapp.jar.

==========

For those wondering about projects using slf4j…How about the SLF4J API?
The SLF4J API is just an API that lets message data go through. As such, using log4j 2.x even via SLF4J does not mitigate the vulnerability.
However, as mentioned previously, log4j 1.x is safe with respect to CVE-2021–44228. Thus, if your SLF4J provider/binding is slf4j-logj12.jar, you are safe regarding CVE-2021–44228.
If you are using log4j-over-slf4j.jar with SLF4J API, you are safe unless the underlying implementation is log4j 2.x.
How do I know if log4j 2.x is in use in my project?
As an artifact can be pulled into a project transitively, looking at explicit dependency declarations may not be sufficient. We suggest that you look into your project’s full dependency tree. For Maven users, this full tree can be obtained with the “mvn dependency:tree” command.
If log4j-core, located in the org.apache.logging.log4j group is absent, then you are fine. Otherwise, either remove the said artifact or upgrade to a log4j 2.x version which fixes the issue.

log4j-Scanner :

There is a patch bypass on Log4J v2.15.0 that allows a full RCE. Full Hunt added community support for log4j-scan to reliably detect CVE-2021–45046. If you’re having difficulty discovering and scanning your infrastructure at scale or keeping up with the Log4J threat, please get in touch at (team@fullhunt.io).

Using docker:

git clone https://github.com/fullhunt/log4j-scan.git
cd log4j-scan
sudo docker build -t log4j-scan .
sudo docker run -it --rm log4j-scan

# With URL list "urls.txt" in current directory
docker run -it --rm -v $PWD:/data log4j-scan -l /data/urls.txt

For more info related to scanner refer to https://github.com/cisagov/log4j-scanner/tree/master/log4-scanner#features

References:-

CVE-2021–44228 — Log4j 2 Vulnerability Analysis — Randori Attack Team

https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot

SLF4J

NVD

NVD

New Local Attack Vector Expands the Attack Surface of Log4j Vulnerability

log4j-scanner/log4-scanner at master · cisagov/log4j-scanner (github.com)