Another vulnerability has been identified in the Log4j 2 library (CVE-2021-45105), which, unlike two previous issues, is classified as dangerous but not critical. This new issue can cause denial of service and manifests as looping and crashes when processing certain strings. The vulnerability has been fixed in the Log4j 2.17 release published just a few hours ago. The threat of the vulnerability is mitigated by the fact that the issue only occurs on systems running Java 8.
Vulnerable systems are those using contextual lookups (Context Lookup) for determining log output format, such as ${ctx:var}. In Log4j versions from 2.0-alpha1 to 2.16.0, there was no protection against uncontrolled recursion, allowing an attacker to manipulate the value used in the substitution, leading to looping that exhausts stack space and crashes the process. Specifically, the problem occurred when substituting values like "${${::-${::-$${::-j}}}}".
Additionally, researchers from Blumira suggested an attack variant on vulnerable Java applications that do not accept external network requests. For example, developer systems or users of Java applications can be targeted. The essence of the method is that if a system has vulnerable Java processes that only accept network connections from localhost or handle RMI requests (Remote Method Invocation, port 1099), an attack can be executed using JavaScript code when users open a malicious page in their browser. To establish a connection with the network port of the Java application during such an attack, the WebSocket API is used, which does not impose same-origin restrictions like HTTP requests do (WebSocket can also be used for scanning network ports on localhost to identify existing network handlers).
Additionally, the published results from Google regarding the vulnerability assessment of libraries related to Log4j are noteworthy. According to Google, the issue affects 8% of all packages in the Maven Central repository. Specifically, 35,863 Java packages, linked to Log4j through direct and indirect dependencies, are vulnerable. Log4j is used as a direct first-level dependency in only 17% of cases, while in 83% of the affected packages, the binding occurs through intermediary packages dependent on Log4j, i.e., second and higher-level dependencies (21% - second level, 12% - third, 14% - fourth, 26% - fifth, 6% - sixth). The pace of vulnerability remediation leaves much to be desired; a week after the vulnerability was identified, the problem has been resolved in only 4,620 of the 35,863 identified packages, which is 13%.
Meanwhile, the U.S. Cybersecurity and Infrastructure Security Agency has issued an emergency directive requiring federal agencies to identify information systems vulnerable to Log4j and to implement updates to mitigate the issue by December 23. By December 28, organizations are required to report on the actions taken. To facilitate the identification of affected systems, a list of products with confirmed vulnerabilities has been prepared (with over 23,000 applications on the list).
Source: opennet.ru
