Apache Log4j exposed the third vulnerability: uncontrolled recursion | Apache has officially released version 2.17 to fix

Since December 10th, Apache Log4j2 has successively exposed multiple vulnerabilities, which have caused an impact on a global scale. Just past December 18th, Apache Log4j was exposed to the third vulnerability: CVE-2021-45105-Apache Log4j 2.0-alpha1 to 2.16.0 version cannot prevent uncontrolled recursion of self-reference search (Apache official has Release 2.17.0 version fix).

(Related Reading:

• High-risk bug! Apache Log4j2 remote code execution vulnerability: The official is rushing to fix it!
  https://segmentfault.com/a/1190000041096729
• Log4j high-risk bug has been fixed overnight! Maintainer: "In order to achieve backward compatibility, the old function was not deleted and the vulnerability was caused."
  https://segmentfault.com/a/1190000041107791）

Vulnerability details

Vulnerability description:

Apache officially stated that for versions of Apache Log4j prior to 2.17.0, when the logging configuration uses a non-default pattern layout with context lookup (PatternLayout and Context Lookup: for example, $${ctx:loginId}), it is very vulnerable The impact of the vulnerability. After successfully exploiting this vulnerability, an attacker with Thread Context Mapping (MDC) input data control rights may forge malicious input data containing recursive search, causing StackOverflower errors and terminating the process. It is also known as a DOS (Denial of Service) attack .

It is reported that the latest vulnerability was discovered by Hideki Okamoto of Akamai Technologies and an anonymous vulnerability researcher. Apache noticed that only Log4j core JAR files are affected by the CVE-2021-45105 vulnerability.

Vulnerability impact:

The attacker successfully exploited this vulnerability or caused a denial of service (DoS).

Vulnerability score details:

CVE：CVE-2021-45105
Rating: 7.5 (high)
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Apache has officially released a fix for version 2.17

Fortunately, on December 19, the vulnerability CVE-2021-45105 Apache Log4j was fixed in the latest official release of Log4j 2.17.0 (Java 8).

Mitigation measures include: applying the 2.17.0 patch and replacing the context lookup such as ${ctx:loginId} or $$${ctx with thread context mapping mode (%X, %mdc or %mdc) in the PatternLayout of the log configuration :loginId}. Apache also recommends removing references to context lookups in configurations such as ${ctx:loginId} or $${ctx:loginId}. These references come from sources external to the application, such as HTTP headers or user input.

Apache official 2.17.0 version link:

https://logging.apache.org/log4j/2.x/security.html

In other words, starting from version 2.17.0 (for Java 8), only the search string in the configuration is expanded recursively; in any other usage, only the top-level search is parsed, and no nested search is parsed.

Since the first "high-risk" remote code execution vulnerability in Apache Log4j2 was discovered in the early morning of December 10, the official version of Apache Log4j 2.15.0 has been released urgently to resolve the vulnerability.

However, in the following days, it was discovered that there was a vulnerability in the Apache Log4j 2.15.0 version of sensitive data leakage, which can be used to download data from the affected server. Then the official recommends that users upgrade to 2.16.0 as soon as possible.

This time, an uncontrolled recursive vulnerability was discovered in Apache Log4j 2.0-alpha1 to 2.16.0. This is the third vulnerability exposed in Apache Log4j.

About Apache Log4j2

Apache Log4j2 was originally written by Ceki Gülcü and is part of the Apache Log Service Project of the Apache Software Foundation. Log4j is one of several Java logging frameworks. And Apache Log4j2 is an upgrade to Log4j. Compared with its predecessor Log4j1, it has more significant improvements and fixes some inherent problems in the Logback architecture.

Through the Apache Log4j2 framework, developers can control the log generation process by defining the level of each log information.

At present, the log framework has been widely used in business system development to record log information. In most cases, developers may write error messages caused by user input into the log.