The impact of the infamous vulnerability in Java library Log4j drags on. Although the biggest problem was solved with urgent patch 2.16, this version also appears to be susceptible to abuse. Security researchers found an entrance for Denial of Service (DoS) attacks. Log4j 2.17 has been published to close the entry.
Apache, developer of the Java library, advises organizations to apply the emergency patch. That advice applies for the third time since the library was found to be vulnerable.
A week and a half ago, security researchers from Alibaba’s cloud security team revealed a method to abuse applications with Log4j. Log4j is used in applications to log events. It turned out to be possible to access applications with the library from outside with instructions for executing malware. Abuse takes little more than a snap. Add to that the estimated occurrence of the library in most corporate environments and you understand the scale of the disaster facing the global IT landscape.
Software developers such as Fortinet, Cisco, IBM and dozens of others use the library in their software. Their developers worked overtime over the weekend December 11 to process the first emergency patch for the vulnerability and deliver it to user organizations. Exactly the same drift was expected from the IT teams within these organizations. Hundreds of thousands of attack attempts took place worldwide. Everyone had to switch to 2.15 as soon as possible – until 2.15 was also found to be vulnerable.
Certain configurations of the library remained possible in version 2.15. Using these configurations perpetuated the vulnerability. Version 2.16 made the configurations impossible, guaranteeing a new patch. Often to the chagrin of already overworked IT teams. However, it can always be worse, because 2.16 also has an ailment.
Back to start
The massive global attention to the problem prompted massive worldwide investigation. Apache, developer of the library, can’t seem to catch his breath for two days without a security company pointing out a new, pressing problem.
In short, it turns out that it is possible to run dozens of versions of log4j – including 2.16 – with one line (string) to start an eternal loop that crashes the application. The conditions that an environment must meet in order to be abused are extensive. So extensive that the practical seriousness of the problem is disputed. The patch is officially recommended, but not everyone is convinced.
Again, not every instance of Log4j is vulnerable, but only cases where the library is running on custom settings. A potential attacker also needs detailed insight into how Log4j works. A contrast to the initial, easily accessible vulnerability.
