CODEWITHSUNDEEP
log4jlog4j2
Berkeley Now
Berkeley Now

Reputation: 137

Doubts about mitigations to Apache's Log4j library vulnerability

On December 9, 2021, a critical vulnerability related to Apache's Log4j library was disclosed. The vulnerability is detailed here. In this link possible mitigations are mentioned. I hope you can help me with the following questions (I apologize in advance in case my questions sound too trivial):

Mitigation 1: set the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. This is made up of 2 different operations:

  1. The first is to set the log4j2.formatMsgNoLookups system property to TRUE. What are and where are the properties of the system?
  2. Or, set the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to TRUE. In appearance this is as easy as running this: export LOG4J_FORMAT_MSG_NO_LOOKUPS=true. Is there a problem with creating that environment variable on a system that doesn't use the Log4j library?

Mitigation 2: all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m. That is, instead of using %m, you have to use %m{nolookups}, and that this is done in all PatternLayout patterns. In this place the possible configuration files of the Log4j library are listed. I managed to find this /usr/lib/appdynamics-php5/proxy/conf/logging/log4j2.xml, which contains multiple lines like this: <PatternLayout pattern="[%t] %d{DATE} %5p %c - %m%n"/>. I guess it's just in those config files where this mitigation needs to be run, and not elsewhere, correct?

Mitigation 3: remove the JndiLookup class from the classpath. For example: zip -q -d log4j-core-.jar org/apache/logging/log4j/core/lookup/JndiLookup.class. I can't find a file called JndiLookup.class anywhere. I suppose that if it does not exist, you do not have to look for anything else and this possible mitigation does not apply, correct?

Upvotes: 0

Views: 591

Answers (1)

Simulant
Simulant

Reputation: 20102

https://access.redhat.com/security/cve/CVE-2021-45046 was released in addition the the first issue you mentioned.
Mitigation 1 does NOT solve this issue.
I am not sure about Mitigation 2, but as it is just a local way to configure the same effect as Mitigation 1, I also expect that it does not protect you from this vulnerability.
Mitigation 3 should still work, As with the removed JndiLookup.class, the class to load data from the internet will be missing. However an attack with the missing class should raise an Exception. Your application should be robust to not crash on that.

The best Mitigation is currently to update to log4j 2.17.0. Always keep up to date with the news and new vulnerabilities published. It might be that there are new vulnerabilities published in the future and you have to update again to a newer version.

Upvotes: 1

Related Questions