[
https://issues.apache.org/jira/browse/LOG4J2-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17459493#comment-17459493
]
Tero Marttila commented on LOG4J2-3221:
---------------------------------------
Cross-posting this here from
[https://github.com/lunasec-io/lunasec/pull/298#issuecomment-993937297] to give
the log4j developers a chance to respond and correct any mistakes - I have yet
to receive any response from priv...@logging.apache.org
---
Applications using log4j pattern layouts including {{{}$\{ctx:...{}}}} lookups
with versions < 2.15 will remain vulnerable to CVE-2021-44228 JNDI-based RCE
and DNS infoleak exploits regardless of the
{{-Dlog4j2.formatMsgNoLookups=true}} mitigation, if the attacker can control
any of the {{org.apache.logging.log4j.ThreadContext}} values used in the
configured context lookups affected by CVE-2021-45046. Do not rely on the
{{-Dlog4j2.formatMsgNoLookups=true}} mitigation unless you are certain that the
application is not using any attacker-controlled context lookups in the log4j
pattern layouts. The {{zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.class}} mitigation remains
effective against the known JNDI-based RCE and DNS infoleak exploits for <
2.15.0.
Applications using log4j pattern layouts including {{{}$\{ctx:...{}}}} lookups
with version 2.15.0 may still lead to ldap/ldaps connections to restricted
local host addresses, if the attacker can control any of the
{{org.apache.logging.log4j.ThreadContext}} values used in the configured
context lookups affected by CVE-2021-45046. The 2.15.0 version is not known to
be vulnerable to the CVE-2021-44228 JNDI-based RCE and DNS infoleak exploits
via context lookups in an application configuration affected by CVE-2021-45046.
---
The more speculative parts:
So the CVE-2021-45046 vector using context lookups is a complete bypass for the
CVE-2021-44228 message lookup based ({{{}-Dlog4j2.formatMsgNoLookups=true{}}})
mitigations on < 2.15.0 and leads to RCE/infoleak for applications using an
affected configuration, but it's only classified as a DoS vulnerability on
2.15.0 thanks to the JNDI hardening - I assume this is related to the localhost
LDAP connections still permitted by
[https://github.com/apache/logging-log4j2/pull/608]
({{{}log4j2.allowedJndiProtocols/Hosts/Classes{}}})?
The {{zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.class}} mitigation may be a
good idea for 2.15.0 as well, to avoid the DoS vulnerability related to the
localhost LDAP connections in affected configurations? This shold no longer be
necessary for 2.15.1-rc1 or 2.16.0 with
[https://github.com/apache/logging-log4j2/commit/44569090f1cf1e92c711fb96dfd18cd7dccc72ea]
({{{}log4j2.enableJndi=false{}}} defaults).
Based on the CVE-2021-45046 text, applications using log4j pattern layouts
including the {{%X}} MDC pattern converter syntax would also be vulnerable, but
I haven't been able to reproduce that myself - I think that usage is far more
common than the {{{}$\{ctx:...{}}}} syntax that I was able to repro with. Until
proven otherwise, you will want to assume that applications using {{%X}} MDC
context lookups with attacker-controlled values in their log4j pattern layouts
are also vulnerable. Thankfully this is generally somewhat feasible to audit a
codebase for, compared to the earlier message-based injections.
You should still update to 2.15.0 to mitigate the RCE/infoleak vulnerabilities,
and 2.16.0 to mitigate the remaining JNDI DoS vulnerabilities.
> JNDI lookups in layout (not message patterns) enabled in Log4j2 < 2.16.0
> ------------------------------------------------------------------------
>
> Key: LOG4J2-3221
> URL: https://issues.apache.org/jira/browse/LOG4J2-3221
> Project: Log4j 2
> Issue Type: Bug
> Reporter: Lucy Menon
> Priority: Major
> Fix For: 2.16.0
>
>
> The mitigation advice for CVE-2021-4428 suggests that for Log4j > 2.10.0 and
> < 2.15.0, the vulnerability can be avoided by setting
> -{{{}Dlog4j2.formatMsgNoLookups=true{}}} or upgrading to 2.15.0. However,
> many users may not be aware that even in this case, lookups used in layouts
> to provide specific pieces of context information will still recursively
> resolve, possibly triggering JNDI lookups. In order to avoid
> attacker-controlled JNDI lookups, users must also either:
> * Ensure that no such lookups resolve to attacker-provided data
> * Ensure that the the JndiLookup class is not loaded
> * Upgrade to log4j2 2.16.0 (untested)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
