[
https://issues.apache.org/jira/browse/LOG4J2-3279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17464909#comment-17464909
]
sumeet sharma commented on LOG4J2-3279:
---------------------------------------
Hi [~rgoers] - thanks for the explanation. I think I might be missing the whole
point you are trying to make.
So I'll give it another try. Please let me know your take on this.
Say, I'm following alternative mitigations as a way to avoid the Log4J upgrade
at all costs.
For someone like me, the security page is sounding like, "no need to upgrade,
you are safe even if you continue applying alternative mitigations irrespective
of your current Log4J version".
Text like "{*}in any release other than 2.16.0{*}" strengthens the impression
that it's OK to apply alternate mitigation on 2.14.0 (in my case) or any other
version.
So, I applied alternative mitigation for CVE-2021-44228 & CVE-2021-45046, which
says:
* Otherwise, \{*}in any release other than 2.16.0{*}, you may remove the
JndiLookup class from the classpath: zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.class
Finally, I applied alternative mitigation for CVE-2021-45105 by using %X
instead of ctx. In some cases, ctx is never used so they are already safe from
this CVE.
Even after all these mitigations, I'm vulnerable to infinite recursion issues
in the message part.
The text in History > Older (discredited) section talks about this issue
briefly but, again, it confuses by saying:
"The safest thing to do is to upgrade Log4j to a safe version, {*}or remove the
JndiLookup class from the log4j-core jar{*}."
Removing JndiLookup class alone is not going to solve the infinite recursion
issue. You need to set log4j2.formatMsgNoLookups (on 2.14.0, in my case) to
really mitigate this.
The point is:
# the mitigation for infinite recursion issue in the message part should be
documented somewhere, explicitly. As of now, it seems missing.
# if there is an implicit assumption, for example, that "to apply mitigation
for vulnerability fixed in version {_}*N*{_}, you should be on log4J version
{_}{*}N-1{*}"{_}, then that must be explicitly documented as well.
> Alternative mitigation documented for CVE-2021-45105 doesn't work for
> messages without context lookup if the Log4J2 consumers are not on version >=
> 2.15
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: LOG4J2-3279
> URL: https://issues.apache.org/jira/browse/LOG4J2-3279
> Project: Log4j 2
> Issue Type: Bug
> Components: Documentation
> Affects Versions: 2.14.0
> Reporter: sumeet sharma
> Priority: Major
>
> Alternative mitigation documented for CVE-2021-45105 doesn't work for
> messages without context lookup if the Log4J2 consumers are not on version >=
> 2.15.
> Official mitigation provided in
> [https://logging.apache.org/log4j/2.x/security.html] reads:
> h3.
> "[CVE-2021-45105|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105]:
> Apache Log4j2 does not always protect from infinite recursion in lookup
> evaluation
> h3. <trimmed for brevity>
> h3. Mitigation
> h4. Log4j 1.x mitigation
> Log4j 1.x is not impacted by this vulnerability.
> h4. Log4j 2.x mitigation
> Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java
> 8 and later).
> *Alternatively, this infinite recursion issue can be mitigated in
> configuration:*
> * *In PatternLayout in the logging configuration, replace Context Lookups
> like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X,
> %mdc, or %MDC).*
> * *Otherwise, in the configuration, remove references to Context Lookups
> like ${ctx:loginId} or $${ctx:loginId} where they originate from sources
> external to the application such as HTTP headers or user input."*
> The alternative mitigation statement seems to be making assumptions.
> The infinite recursion issue in the message part of the log seems to be fixed
> in version 2.15. Versions prior to that (I tried on 2.14.0), this issue is
> still applicable. **
> Assuming a user is on Log4J 2.14.0, if they follow this mitigation step by
> step, they will still be able to reproduce infinite recursion issue.
> pom.xml
> {code:java}
> <dependencies>
> <dependency>
> <groupId>org.apache.logging.log4j</groupId>
> <artifactId>log4j-api</artifactId>
> <version>2.14.0</version>
> </dependency>
> <dependency>
> <groupId>org.apache.logging.log4j</groupId>
> <artifactId>log4j-core</artifactId>
> <version>2.14.0</version>
> </dependency>
> </dependencies> {code}
> Code:
> {code:java}
> LOG.info("Problematic payload {}", "${${::${::$${::-j}}}}");
> LOG.info("Problematic payload ${${::${::$${::-j}}}}");{code}
>
> Log4j2.xml
> {code:java}
> <Console name="Console" target="SYSTEM_OUT">
> <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level
> %logger{36} - %m%n"/>
> </Console>{code}
>
> Output
> {code:java}
> 2021-12-23 14:40:49,031 main ERROR An exception occurred processing Appender
> Application java.lang.IllegalStateException: Infinite loop in property
> interpolation of ::-${::-$${::-j}}: : {code}
>
> If this stands true, then the documentation should mention:
> * either the minimum required version
> * or usage of -Dlog4j2.formatMsgNoLookups=true for the alternative
> mitigation to work.
>
> I've only kept 2.14.0 as the affected version as I tested on same but this
> might be applicable to quite a few versions.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
