Re: CVE-2021-45046: Apache Log4j2 Thread Context Message Pattern and Context Lookup Pattern vulnerable to a denial of service attack

[Moritz Bechler <mbechler () eenterphace org>]

Hi,

> > 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 [DoS]...
>
> Is there any information on the non-default configuration that triggers the DoS?
>
> What I am trying to understand is, if we clear the first CVE through,
> say, envar LOG4J_FORMAT_MSG_NO_LOOKUPS=true or
> -Dlog4j2.formatMsgNoLookups=true, then where does the vulnerability
> lie for the second CVE? What configuration change needs to be done to
> reduce risk on the second CVE after the first CVE has been mitigated?

[not affiliated with log4j, but maybe I can still shed some light]

The issue is that expansion of the lookup expressions was only disabled 
for the message contents, not within the layout pattern formatting.

The thread local MDC context may contain information that can be 
controlled by an attacker (if used). If you then have a layout pattern 
configured that includes such information, e.g. $${ctx:name} [the 
mentioned vectors via %X, %mdc, or %MDC I personally (and I think 
others) could not easily replicate, maybe there is some trick to it], 
expansion of an attacker provided expression will still happen and can 
be exploited.

For versions <2.15 this renders log4j2.formatMsgNoLookups=true 
ineffective if such a layout configuration is used.

For =2.15 this is mostly mitigated by the fact protocol and target host 
to which lookups are possible are also restricted to localhost by 
default. There still seems to be a way to hang/crash the process, thou.

You could probably check whether any of the layouts used contain any MDC 
data, but imho, if you want to avoid surprises you would really be 
better off patching. Not sure why you would not be able to update.



Moritz