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.
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. -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.
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.
+ +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.
+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.
+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.