Another vulnerability found in Log4j, this time it is a denial of service

Log4Shell, recently discovered in the popular logging library Log4j, which is part of the Apache Logging Project, continues to get worse, as another vulnerability has been found. This time it is time a “denial of service” vulnerability.

The problem was originally discovered while catching bugs on Minecraft servers, but the Log4j library is present in almost all corporate applications and Java servers. For example, it can be found in almost all enterprise products released by the Apache Software Foundation, including Apache Struts, Apache Flink, Apache Druid, Apache Flume, Apache Solr, Apache Kafka, Apache Dubbo. Log4j is also actively used in open-source projects such as Redis, Elasticsearch, Elastic Logstash or Hydra.

I also said that Log4j vulnerability threatens 35,000 Java packages.

Thus, companies using any of these products are also indirectly vulnerable to attacks on Log4Shell, although they may not even know about it. Information security experts immediately warned that the solutions of such giants as Apple, Amazon, Twitter, Cloudflare, Steam, Tencent, Baidu, DIDI, JD, NetEase, and probably thousands of other companies could be vulnerable to Log4Shell.

The way Log4Shell works is simple: the vulnerability forces Java-based applications and servers that use the Log4j library to log a specific string. When an application or server processes such logs, a string can cause the vulnerable system to load and run a malicious script from the attacker’s controlled domain. The result will be a complete hijacking of the vulnerable application or server, and the attack can develop further.the experts said.

It was previously revealed that the first patch for the original problem CVE-2021-44228 (version 2.15) only introduced a new RCE vulnerability CVE-2021-45046 to Log4j, which received 9 points out of 10 on the CVSS vulnerability rating scale.

Because of this, administrators were strongly advised to use only the current version 2.16 and follow further developments on the Log4j update page. The fact is that in Log4j version 2.15, two more less dangerous vulnerabilities were found (CVE-2021-4104 and CVE-2021-42550), which were also eliminated only with the release of version 2.16.

Unfortunately, version 2.16 didn’t last long either. Last weekend, Log4j version 2.17 was released, as a serious denial of service (DoS) issue was detected in the last release, which received the identifier CVE-2021-45105 (7.5 on the CVSS scale). The bug is related to the fact that Log4j does not always protect against infinite recursion during lookup evaluation.

At the same time, experts urge not to panic and not to rush to abandon the use of Log4j at all.

It shouldn’t come as a surprise that additional vulnerabilities are being discovered in Log4j, given the increased focus on the library. Likewise, the discovery of a PrintNightmare vulnerability over the summer resulted in the discovery of many additional individual issues. The discovery of additional vulnerabilities in Log4j should not raise concerns about the security of the library itself. In fact, Log4j is more secure because of the extra attention that researchers are giving to it.commented Jake Williams, CTO and co-founder of BreachQuest

By Vladimir Krasnogolovy

Vladimir is a technical specialist who loves giving qualified advices and tips on GridinSoft's products. He's available 24/7 to assist you in any question regarding internet security.

Leave a comment

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