From 53a9833a3cdac18aed9dab7a0e6894fa1c77edfb Mon Sep 17 00:00:00 2001 From: Ceki Gulcu Date: Mon, 13 Dec 2021 20:16:44 +0100 Subject: [PATCH] read only access Signed-off-by: Ceki Gulcu --- slf4j-site/src/site/pages/log4shell.html | 115 +++++++++++++++-------- 1 file changed, 76 insertions(+), 39 deletions(-) diff --git a/slf4j-site/src/site/pages/log4shell.html b/slf4j-site/src/site/pages/log4shell.html index 16312fe6..869d2278 100644 --- a/slf4j-site/src/site/pages/log4shell.html +++ b/slf4j-site/src/site/pages/log4shell.html @@ -7,10 +7,11 @@ SLF4J - - + + +
@@ -31,10 +32,10 @@

Preamble

-

The JNDI serialization rabbit hole goes deep and leads to - much uncertainty. Thus, the contents of this page are the - result of our current knowledge and are provided AS IS without - warranty of any kind.

+

The JNDI/LDAP/RMI/X serialization rabbit hole goes deep and + leads to much uncertainty. Thus, the contents of this page + are the result of our current knowledge and are provided AS IS + without warranty of any kind.

What is CVE-2021-44228?

@@ -57,38 +58,38 @@ lookup, aka string substitution, using the JNDI protocol, whenever the "${jndi:...}" string is found within a message parameter. As mentioned above, the contents of - the message parameter can be injected by the attacker quite - easily.

+ the message parameter can be injected quite easily by the + attacker.

Is log4j 1.x vulnerable?

As log4j 1.x does NOT offer a look-up mechanism, it does NOT suffer from CVE-2021-44228.

+ green">NOT offer a JNDI look-up mechanism at the message + level, it does NOT suffer from + CVE-2021-44228.

Given that log4j version 1.x is still very widely deployed, - we have been receiving a steady stream of questions regarding - the vulnerability of log4j version 1.x. + perhaps 10 times more than log4j 2.x, we have been receiving a + steady stream of questions regarding the vulnerability of log4j + version 1.x.

-

As log4j 1.x does NOT offer - a look up mechanism, it does NOT - suffer from CVE-2021-44228.

+ a JNDI look up mechanism at the message level, it does NOT suffer from CVE-2021-44228.

-

Does a similar vulnerability exist in logback?

- -

Logback does NOT offer a - lookup mechanism at the message level. Thus, it is deemed safe - with respect to CVE-2021-44228. However, we are still looking at - other possible vulnerabilities of lesser severity. Indeed, the - JNDI/serialization vulnerability is a true minefield.

+

However, log4j 1.x comes with JMSAppender which + will perform a JNDI lookup if enabled in log4j's configuration + file, i.e. log4j.properties or + log4j.xml. Thus, an attacker who has write access to an + application's log4j configuration file can perform an RCE attack + whenever log4j 1.x reads a corrupt/malicious configuration + file. More on this below.

How about the SLF4J API?

- - +

The SLF4J API is just an API which lets message data go - through. As such, using log4j 2.x even via SLF4J does not + through. As such, using log4j 2.x, even via SLF4J does not mitigate the vulnerability.

@@ -100,21 +101,57 @@

If you are using log4j-over-slf4j.jar with SLF4J API, you are safe unless the underlying implementation is log4j 2.x.

+ +

Does a similar vulnerability exist in logback?

-

How do I know if log4j 2.x is in use in my project?

+

Logback does NOT offer a + lookup mechanism at the message level. Thus, it is deemed safe + with respect to CVE-2021-44228. However, we are still looking at + other possible vulnerabilities of lesser + severity. Indeed, the JNDI/RMI/LDAP serialization + vulnerabilities are a true minefield.

-

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.

+

Concrete protective + measure: write protect log4j{1,2}/logback configuration + files

-

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.

+

While there are obviously differences between JNDI/LDAP/RMI + serialization attacks, from an abstract point of view, they are + all related to serialization, the gift that never seems to stop + giving.

+ +

At this point, we hope that you appreciate the distinction + between serialization attacks where the injection of malicious + input is performed at the level of 1) log message data 2) + configuration file. The point of injection matters, a lot. If + you understand the difference, please read on.

+ +

While log4j 1.x is old, it is still very extensible. So are + logback and log4j 2.x.

+

What if there exist other vulnerable extension points, in any + of the aforementioned logging frameworks, that we do not know + about? Do you think you can enumerate these weak points by + searching a CVE database?

+

Trying to harden JMSAppender in log4j 1.x or + some other component in log4j 2.x or logback against + serialization injection seems like a half-measure. If you are + fond of analogies, it is a bit like trying to empty a bathtub + with a leaky faucet armed only with a spoon. +

+ +

Therefore, in addition to hardening KNOWN vulnerable + components in aforementioned frameworks, we also recommend that + configuration files be protected against write access. In + Unix-speak they should be read-only for all users, including the + owner. If possible, they should also be monitored + against changes and unauthorized manipulation.

+ +

If you have read this far, you might also get an "Aha but + wait!" moment related to serialization attacks but having + nothing to do with logging.

+

Is there a bigger lesson?

CVE-2021-44228 involves a cascade of failures in various @@ -127,12 +164,12 @@

Thus, while keeping up with the latest patches is a good practice, it is probably just as important to invest resources so that your organization is capable of understanding the actual - root causes of various vulnerabilities and can avoid them in the - first place.

+ root causes of vulnerabilities and avoid them in the first + place.

Another question is the reaction speed. Once a vulnerability - is detected, can your organization quickly fix a vulnerability? - On this front, the log4j 2.x developers deserve credit for their + is detected, can your organization fix a vulnerability quickly? + On this front, log4j 2.x developers deserve credit for their quick response.