diff --git a/slf4j-site/src/site/pages/log4shell.html b/slf4j-site/src/site/pages/log4shell.html index 869d22787..3c56bc3af 100644 --- a/slf4j-site/src/site/pages/log4shell.html +++ b/slf4j-site/src/site/pages/log4shell.html @@ -32,7 +32,7 @@

Comments on the CVE-2021-44228 vulnerability

Preamble

-

The JNDI/LDAP/RMI/X serialization rabbit hole goes deep and +

The JNDI/LDAP/RMI/X serialization rabbit hole runs 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.

@@ -69,7 +69,7 @@

Is log4j 1.x vulnerable?

CVE-2021-44228.

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

@@ -80,12 +80,46 @@

Is log4j 1.x vulnerable?

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.

- + file, i.e. log4j.properties or log4j.xml.

+ +

An attacker who ALREADY has write access the log4j + configuration file will need to add JMSAppender + into the configuration poisoned with malicious connection + parameters. Note that prior legitimate usage of + JMSAppender is irrelevant to the ability of the + attacker to mount a successful attack.

+ +

Also note that poisoning the configuration file is not + enough. The attacker also needs to force log4j to reload its + configuration file with the poisoned parameters. Given that + log4j 1.x does not offer automatic reloading, the poisoned + configuratin file will typically only become effectve at + application restart.

+ +

Nevertheless, while not easy, such an attack is + feasible. Thus it makes sense to make job of the attacker harder + by removing JMSAppender altogether from + log4j-1.2.17.jar.

+ +

In the absence of a new log4j 1.x release, you can remove + JMSAppender from the log4j-1.2.17.jar + artifact yourself. Here is the command:

+ + 
   zip -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class
+ +

If you do not have access to 'zip', you can also use the + 'jar' command.

+ + 
   #assuming log4j-1.2.17.jar exists in current directory
+   mkdir tmp
+   cd tmp
+   jar xvf ../log4j-1.2.17.jar
+   rm org/apache/log4j/net/JMSAppender.class
+   jar cvf ../log4j-1.2.17-patched.jar .
+ +

It goes without saying that once log4j-1.2.17.jar is + patched, you would need to deploy it.

+

How about the SLF4J API?

The SLF4J API is just an API which lets message data go @@ -93,93 +127,87 @@

How about the SLF4J API?

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 +

However, as mentioned already, 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.

+

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

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/RMI/LDAP serialization - vulnerabilities are a true minefield.

+ with respect to CVE-2021-44228.

+ +

However, logback may make JNDI calls from within its + configuration file. This was recently + reported as a vulnerability of lesser severity. In response, we have released + logback version 1.2.8. Please upgrade. +

-

Concrete protective +

Note that the vulnerability affecting logback requires write + access to logback's configuration file as a prerequisite. To + escalate to a succesful Remote Code Execution attack, ALL of the + following conditions have to be met: +

+ + +
    +
  1. attacker has write access to logback.xml
    2. +
  2. use of logback version older than 1.2.8
    3. +
  3. loading of poisoned configuration data, which implies + application restart or scan="true" set prior to attack
    4. +
+ +

As a belt-and-suspenders type of precaution, in addition to + upgrading to logback version 1.2.8, we also recommend users to + deploy their logback configuration files as read-only.

+ + +

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

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.

+ all related to serialization, the gift that keeps 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.

+ between serialization attacks where malicious input is injected + via "log message data" versus a "configuration file". The point of + injection matters a lot. The former attack point requires no + privilege whereas the latter requires significant prior + privilege. 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. -

+ serialization injections (via configuration files) will be a + long and ardous task. Moreover, we think you should err on the + side of caution by assuming that there will remain hidden + vulnerabilities.

+ +

We recommend that you err on the side of + caution by deploying configuration files with read-only + permissions.

+

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 + components, we also recommend that configuration files be + protected against write access. In Unix-speak they should have + read-only permissions 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 - components, of which only one is actually located in log4j - 2.x. Indeed, it takes only a moment of inattention to - unwittingly create a vulnerability. However, vulnerabilities may - arise even when you follow best practices. -

- -

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 vulnerabilities and avoid them in the first - place.

- -

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

- -

Conclusion

- -

CVE-2021-44228 became public knowledge in 2021-12-10, about - 48 hours ago. It raises a number of very tough questions which - are not necessarily related to logging. As mentioned at the top - of this page, the JNDI serialization rabbit hole goes deep and - leads to much uncertainty. We are still investigating.

Further reading

diff --git a/slf4j-site/src/site/pages/mailing-lists.html b/slf4j-site/src/site/pages/mailing-lists.html index 73d2f9acd..00023a9d3 100755 --- a/slf4j-site/src/site/pages/mailing-lists.html +++ b/slf4j-site/src/site/pages/mailing-lists.html @@ -11,7 +11,8 @@ -
+ +
diff --git a/slf4j-site/src/site/pages/templates/left.js b/slf4j-site/src/site/pages/templates/left.js index 00f7ab2ba..d90da2648 100755 --- a/slf4j-site/src/site/pages/templates/left.js +++ b/slf4j-site/src/site/pages/templates/left.js @@ -14,7 +14,7 @@ document.write(' Source Repository< document.write(' Support offerings'); document.write('

Native implementations

'); -document.write(' Logback'); +document.write(' Logback'); document.write('

Wrapped implementations

'); document.write(' JDK14'); @@ -29,7 +29,7 @@ document.write('
'); document.write('

 

'); document.write('
'); -document.write(' '); +document.write(' '); document.write(' Follow @qos_ch'); document.write(' '); document.write('
');