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.
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.