A New New New New Log4J Vulnerability
Yesterday, December 18, 2021, we released an overview of all the Log4j news from the past week (https://www.connectwise.com/resources/log4j-update). At the end of the day yesterday, the Apache Software Foundation released yet another version of Log4j, version 2.17.0, to address yet another vulnerability. The latest vulnerability, CVE-2021-45105 (https://nvd.nist.gov/vuln/detail/CVE-2021-45105), has a CVSS score of 7.5, much better than the 10.0 of the original vulnerability.
This new CVE is caused by improper user validation and results in a potential denial of service attack. I was discussing the list of Log4j vulnerabilities with R.J. McDown (https://twitter.com/beetlechunks), a Senior Security Engineer from the Equinix (https://www.equinix.com/) Red Team who independently ran across what became CVE-2021-45105 simultaneously as it was being reported to Apache by Hideki Okamoto (https://jp.linkedin.com/in/hideki-okamoto-28366769/en-us) of Akamai Technologies (https://www.akamai.com/) and an anonymous vulnerability researcher. According to McDown, “This vulnerability is exploited when an attacker can introduce a specially crafted string into an application that performs a lookup on that string. Current testing has allowed exploitation of this vulnerability in log4j 2.16.0 when the given string is used in the Thread Context Map and the log4j layout pattern references those strings via an explicit lookup.”
According to the Apache Software Foundation’s advisory at https://logging.apache.org/log4j/2.x/security.html:
“Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from 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.”
This bug was originally reported as an issue to Apache’s Jira three days ago, on December 15, https://issues.apache.org/jira/browse/LOG4J2-3230. After several days of discussions and testing it was confirmed that this vulnerability could be used in a DOS attack; however, it does require a very specific edge case, with a non-default configuration option, specifically a non-default “PatternLayout”. With the non-default configuration options in place, and if a few other conditions are met, a string such as "${${::-${::-$${::-j}}}}" could cause infinite recursion, which could result in a Denial of Service. It is important to point out that the risk for this vulnerability is very low, but not zero.
Yesterday, we were recommending everyone upgrade Log4j to version 2.16.0. Today, the recommendation is to upgrade to 2.17.0. Regarding previous JNDI vulnerabilities, CVE-2021-44228 and CVE-2021-45046, Apache did recommend the following command to remove the JndiLookup.class in order to mitigate where an upgrade is not yet possible:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.classUnfortunately, this latest CVE is not related to JNDI, so none of the previously recommended methods for mitigating the other Log4j vulnerabilities discovered over the past couple weeks will mitigate this latest vulnerability. The only currently known method for completely mitigating all known Log4j vulnerabilities is to upgrade to the latest version, 2.17.0.
References
https://www.connectwise.com/resources/log4j-update
https://www.connectwise.com/resources/major-vulnerability-in-the-most-common-java-logging-module
https://www.connectwise.com/resources/updates-for-log4j-and-december-patch-tuesday
https://nvd.nist.gov/vuln/detail/CVE-2021-45105