Update Log4j dependency to 2.16.0 to address Log4Shell/LogJam
Description
Environment
relates to
Activity
Jason Heffner December 22, 2021 at 1:17 PM
Thanks, really appreciate your due diligence. Because of the heightened awareness of log4j recently there has been a lot more pressure to make sure everything is resolved.
Guus der Kinderen December 19, 2021 at 5:04 PM
I have raised for 2.17.0. The vulnerability fixed in that does not appear to be applicable to Openfire though.
Jason Heffner December 18, 2021 at 4:16 PM
2.17.0 just dropped this morning (CVE-2021-45105) to address a potential DoS vulnerability
Guus der Kinderen December 16, 2021 at 3:00 PM
Updated to log4j2 2.16.0 & Put in place both mitigations mentioned in issue description.
Guus der Kinderen December 14, 2021 at 6:19 PM
A new CVE was issued:
It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack. Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default. Note that previous mitigations involving configuration such as to set the system property `log4j2.noFormatMsgLookup` to `true` do NOT mitigate this specific vulnerability. Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default. This issue can be mitigated in prior releases (<2.16.0) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).
After the initial release of log4j 2.15.0, to address the Log4Shell vulnerability, the log4j community was fast to put out a new release: 2.16.0. This seems to build on the earlier work that addresses the vulnerability.
It is suggested (although I've not seen proof yet) that 2.16.0 closes further attack vectors (see https://issues.apache.org/jira/browse/LOG4J2-3221)
We'd best at the very least prepare an upgrade from 2.15.0 to 2.16.0.
Also, consider including the mitigation tactics of:
adding
log4j2.formatMsgNoLookupsas a system property to the startup scriptsspecifying the message converter as %m{nnolookups} instead of just %m in the log4j2.xml file
These should be mutually exclusive and unneeded when upgraded, but perhaps not depending on one fix (which might prove to not fully protect in the future) isn't the worst strategy.