Log4j Vulnerability - Saga Continues

To everyone's surprise, the latest release of log4j 2.16.0 is now effected by Denial of Service vulnerability and is claimed to be fixed in another release 2.17.0.



This Denial of Service vulnerability is reported by Hideki Okamoto of Akamai technologies and other vulnerabilities researchers.

Versions Impacted

CVE

Severity

Type of Vulnerability

Fixed in

< 2.16.0

7.5

Denial of Service

2.17.0

< 2.15.0

9.0 (earlier 3.5)

Remote Code Execution

2.16.0

< v2.14.0

10

Remote Code Execution

2.15.0

You can refer to the older vulnerabilities details and its mitigation steps in these post:


Vulnerability - Uncontrolled Recursion from Self-Referential Lookups


When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process. This is also known as a DOS (Denial of Service) attack.

Mitigation

In order to fix this, it is suggested to upgrade the log4j version to 2.17.0

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.17.0</version>
</dependency>

But there is also an alternative step provided also

  • 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.

So basically what it means is if there is a lookup in your log4j configuration file, then remove it in order to protect yourself from this vulnerability. The applications having these lookups will look something like this

<File name="Application" fileName="application.log">
  <PatternLayout>
    <pattern>%d %p %c{1.} [%t] $${ctx:loginId} %m%n</pattern>
  </PatternLayout>
</File>

Also, it is suggested that instead of lookups like $${context.loginid} use Thread Context Map patterns. The Thread Context Map are introduced in log4j 2.x and are referred as Mapped Diagnostic Context, where as the Thread Context Stack is the Nested Diagnostic Context introduced in log4j 1.x.


The Stack and Map are managed per thread and are based on ThreadLocal by default.


It can configured using following parameters:

  • Set the system property disableThreadContextMap to true to disable the Thread Context Map.

  • Set the system property disableThreadContextStack to true to disable the Thread Context Stack.

  • Set the system property disableThreadContext to true to disable both the Thread Context Map and Stack.

  • Set the system property log4j2.isThreadContextMapInheritable to true to enable child threads to inherit the Thread Context Map.

When the content is pushed to these map and stack, pattern layout also provide options to print the contents of the Thread Context Map and Stack using

  • %X by itself to include the full contents of the Map.

  • %X{key} to include the specified key.

  • %x to include the full contents of the Stack.

Also this vulnerability is only present in the log4j-core jar file and if your application is using only log4j-api, then it is not impacted.


References


Please do suggest more content topics of your choice and share your feedback. Also subscribe and appreciate the blog if you like it.

86 views0 comments

Recent Posts

See All