Another vulnerability has been identified in the Log4j 2 library (CVE-2021-45105), which, unlike the previous two problems, is categorized as dangerous, but not critical. A new problem allows you to cause a denial of service and manifests itself in the form of a loop and crash when processing certain lines. The vulnerability was fixed in the Log4j 2.17 release published a few hours ago. The danger of the vulnerability is mitigated by the fact that the problem only manifests itself on systems with Java 8.
Vulnerabilities affect systems that use Context Lookups, such as ${ctx:var}, to determine the log output format. Versions of Log4j from 2.0-alpha1 to 2.16.0 lacked protection against uncontrolled recursion, which allowed an attacker to manipulate the value used in substitution to cause a loop that would run out of stack space and cause the process to crash. In particular, the problem occurred when substituting values ββsuch as "${${::-${::-$${::-j}}}}".
Additionally, it can be noted that researchers from the Blumira company have proposed a variant of attacking vulnerable Java applications that do not accept external network requests, for example, it is possible to attack the systems of developers or users of Java applications in this way. The essence of the method is that if there are vulnerable Java processes on the user's system that accept network connections only from the local host (localhost), or process RMI requests (Remote Method Invocation, port 1099), the attack can be carried out by JavaScript code executed by when users open a malicious page in a browser. This attack uses the WebSocket API to establish a connection to a Java application's network port, which, unlike HTTP requests, is not subject to same-origin restrictions (WebSocket can also be used to scan network ports on the local host to determine available network handlers).
Also of interest is the vulnerability assessment results published by Google for libraries associated with Log4j dependencies. According to Google, the issue affects 8% of all packages in the Maven Central repository. In particular, 35863 Java packages related to Log4j with direct and indirect dependencies were affected by vulnerabilities. At the same time, Log4j is used as a direct dependency of the first level only in 17% of cases, and in 83% of the packages covered by the vulnerability, the binding is carried out through intermediate packages that depend on Log4j, i.e. dependencies of the second and higher levels (21% - the second level, 12% - the third, 14% - the fourth, 26% - the fifth, 6% - the sixth). The pace of fixing the vulnerability so far leaves much to be desired, a week after the vulnerability was discovered, out of 35863 identified packages, the problem has been fixed so far only in 4620, i.e. at 13%.
Meanwhile, the US Cybersecurity and Infrastructure Protection Agency has issued an emergency directive requiring federal agencies to identify information systems affected by the Log4j vulnerability and install patches blocking the problem by December 23. Until December 28, organizations are required to report on the work done. To simplify the identification of problematic systems, a list of products has been prepared in which a vulnerability has been confirmed (the list contains more than 23 applications).
Source: opennet.ru