They identified another vulnerability Log4j 2 and it is marked as dangerous

log4j

A few weeks ago, the news of Log4j's security problems was turning many users on the network upside down and it is one of the flaws that has been exploited the most and which many experts have labeled as "the most dangerous in a long time », Of the vulnerabilities that were made known in the network we talk about some of them here on the blog and this time we have found the news of another.

And it is that a few days ago the news was released that another vulnerability was identified in the Log4j 2 library (which is already listed under CVE-2021-45105) and which, unlike the previous two issues, was classified as dangerous, but not critical.

The new problem allows a denial of service and manifests itself in the form of loops and abnormal terminations when processing certain lines.

Vulnerability affects systems that use context search, such as $ {ctx: var}, to determine the log output format.

All the Log4j versions 2.0-alpha1 to 2.16.0 lacked protection against uncontrolled recursionWhich allowed an attacker to manipulate the value used in substitution to cause an endless loop that would run out of space on the stack and cause the process to hang. In particular, the problem occurred when substituting values ​​such as "$ {$ {:: - $ {:: - $$ {:: - j}}}}".

In addition, It can be noted that Blumira researchers have proposed an attack on vulnerable Java applications that do not accept requests from external networks, for example, systems of developers or users of Java applications can be attacked 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 performed by executed JavaScript code when the user opens a malicious page in the browser. To establish a connection to the network port of a Java application in such an attack, the WebSocket API is used, to which, unlike HTTP requests, no same-origin restrictions are applied (WebSocket can also be used to scan network ports on the local host to determine available network drivers).

The results of evaluating the vulnerability of the libraries associated with dependencies with Log4j published by Google are also of interest. According to Google, the problem affects 8% of all packages in the Maven Central repository.

In particular, 35863 Log4j related Java packages with direct and indirect dependencies were exposed to vulnerabilities. In turn, 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 done through intermediate packages that depend on Log4j, that is, tell. dependencies of the second and highest level (21% - the second level, 12% - the third, 14% - the fourth, 26% - the fifth, 6% - the sixth).

The rate of repair of the vulnerability still leaves much to be desired, a week after the vulnerability was identified, out of 35863 packages identified, the problem has been fixed so far only in 4620, that is, to 13%.

Changes to packages are necessary to update dependency requirements and replace old version bindings with fixed versions of Log4j 2 (Java packages practice binding to a specific version, and not an open range that allows installation of the latest version).

Elimination of the vulnerability in Java applications is hampered by the fact that programs often include a copy of the libraries in delivery, and it is not enough to update the Log4j 2 version in the system packages.

Meanwhile, the U.S. Agency for Infrastructure Protection and Cybersecurity issued an emergency directive requiring federal agencies to identify information systems affected by the Log4j vulnerability and install updates that block the problem. before December 23.

On the other hand, a guideline was given until December 28, in which the organizations had the obligation to report on the work carried out. To simplify the identification of problematic systems, a list of products in which the manifestation of a vulnerability has been confirmed has been prepared (there are more than 23 thousand applications in the list).

Finally, It is worth mentioning that the vulnerability was fixed in Log4j 2.17 which was published a few days ago and users who have the updates disabled are recommended to carry out the corresponding update, in addition to the fact that the danger of the vulnerability is mitigated by the fact that the problem only manifests itself on systems with Java 8.

Source: https://logging.apache.org/


Be the first to comment

Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: AB Internet Networks 2008 SL
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.