You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "Ralph Goers (Jira)" <ji...@apache.org> on 2022/01/06 23:00:00 UTC
[jira] [Comment Edited] (LOG4J2-3279) 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
[ https://issues.apache.org/jira/browse/LOG4J2-3279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17470230#comment-17470230 ]
Ralph Goers edited comment on LOG4J2-3279 at 1/6/22, 10:59 PM:
---------------------------------------------------------------
The infinite recursion happens when a user passes an infinitely recursive lookup string in an HTTP header (for example) and you store that in a ThreadContext variable which you then reference in something evaluated as part of event processing - such as the Route on a routing appender. If you know you aren't putting unverified data into ThreadContext variables that are then referenced in the configuration when processing logging events then you are not subject to the problem - with one caveat.
The original security report - CVE-2021-44228 allowed lookups to be processed when they appeared in the data being logged. To avoid that you either need to set the system property or use the \{nolookups} option on the %m converter in the PatternLayout. However, you will noticed that in the history section of two of the CVEs it is called out that these mitigations are insufficient. They do work for the vast majority of logging but if you have code that uses logger.printf(), or uses one of the alternate MessageFactories then those events are not blocked from processing lookups. If you are 100% sure your code doesn't have anything but vanilla format strings (for example if you use SLF4J you cannot have anything else) then this mitigation would work. If you are unsure you MUST upgrade.
To be clear, the only solution the Log4j team can really recommend is to upgrade to 2.3.2, 2.12.4 or 2.17.1 to be absolutely sure as well as to be in compliance with things like [https://techcrunch.com/2022/01/05/ftc-legal-action-log4j/]. Alternate mitigation strategies should only be viewed as short term actions to be taken until you can upgrade.
was (Author: ralph.goers@dslextreme.com):
The infinite recursion happens when a user passes an infinitely recursive lookup string in an HTTP header (for example) and you store that in a ThreadContext variable which you then reference in something evaluated as part of event processing - such as the Route on a routing appender. If you know you aren't putting unverified data into ThreadContext variables that are then referenced in the configuration when processing logging events then you are not subject to the problem - with one caveat.
The original security report - CVE-2021-44228 allowed lookups to be processed when they appeared in the data being logged. To avoid that you either need to set the system property or use the \{nolookups} option on the %m converter in the PatternLayout. However, you will noticed that in the history section of two of the CVEs it is called out that these mitigations are insufficient. They do work for the vast majority of logging but if you have code that uses logger.printf(), or uses one of the alternate MessageFactories then those events are not blocked from processing lookups. If you are 100% sure your code doesn't have anything but vanilla format strings (for example if you use SLF4J you cannot have anything else) then this mitigation would work. If you are unsure you MUST upgrade.
To be clear, the only solution the Log4j team can really recommend is to upgrade to 2.3.2, 2.12.4 or 2.17.1 to be absolutely sure as well as to be in compliance with things like https://techcrunch.com/2022/01/05/ftc-legal-action-log4j/.
> 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)