The patch (version 2.15.0) to fix the critical Log4Shell vulnerability in the Log4j Java-based logging utility (CVE-2021-44228) did not fully correct the vulnerability and certain non-default configurations of Log4j were still vulnerable. The issue was assigned a different CVE – CVE-2021-45046 – and was corrected in version 2.16.0.
The CVE-2021-45046 vulnerability could be exploited and used to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack, although it was later determined it could lead to information disclosure and remote code execution. The vulnerability was given a CVSS severity score of 9.0 out of 10. Log4j 2.16.0 fixed the problem by removing support for message lookup patterns and also disabling JNDI functionality by default.
Now another version of Log4j has been released to fix a third vulnerability, CVE-2021-45105, which could also be exploited in a denial-of-service attack. The vulnerability is high severity and has a CVSS score of 7.5 out of 10 and has been fixed in version 2.17.0.
“Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from uncontrolled recursion from self-referential lookups,” according to the Apache Software Foundation (ASF).“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.”
All organizations that use Log4j have been advised to update once again to the latest version to prevent exploitation of the vulnerability.
The latest version was released shortly after researchers at the cybersecurity company Blumira identified a new attack vector for exploiting the original log4Shell vulnerability, with further expands the attack surface. While the original CVE-2021-44228 vulnerability was limited to exposed and vulnerable servers, it is also possible to exploit the flaw with a JavaScript WebSocket attack vector through the path of a listening server on the machine or local network.
This attack vector could be used on services running as localhost that are not exposed to a network. Since the client has no direct control over WebSocket connections, they can be silently started while a webpage loads, which means it can be exploited by navigating to a specially crafted website. All the more reason to ensure the vulnerability is patched promptly.
