The impact of the infamous vulnerability in Java library Log4j drags on. Although the initial issue was resolved with patches 2.14, 2.15 and 2.16, the latter version appears to be susceptible to abuse as well. Security researchers found an entrance for Denial of Service (DoS) attacks. Log4j 2.17 was published to close it off.
The library’s developer, Apache, urges organizations to apply the emergency patch. The third consecutive advice since the library was found vulnerable.
A week and a half back, security researchers from Alibaba’s cloud security team revealed a method of exploiting applications with Log4j. Log4j is used in applications to log events. It proved possible to approach applications using Log4j with instructions to execute malware. Abuse requires little more than a literal flick of the wrist. In combination with the fact that the library is estimated to operate in most corporate environments, it’s easy to understand the scale of the disaster facing the global IT landscape.
Software developers like Fortinet, Cisco, IBM and dozens of others use the library in their software. Their developers worked overtime over the weekend of December 11 to process and deliver the first emergency patch to their userbase. The same drive was expected of the IT teams of organizations among this userbase. Hundreds of thousands of attack attempts took place worldwide. Everyone was urged to move to 2.15 as quickly as possible — until 2.15 was found to be vulnerable as well.
Certain configurations of the library remained possible in version 2.15. Using these configurations kept the vulnerability alive. Version 2.16 made the configurations impossible. Another patch was warranted, often to the annoyance of overworked IT teams. Yet, things can always get worse. 2.16 has a malady as well.
Back to square one
The massive, worldwide attention to the problem invited massive, worldwide research. Apache, the developer of the library, can’t seem to catch its breath for two consecutive days without a security company pointing out a new, urgent problem.
In short, it now appears possible to feed most versions of Log4j with string to start an eternal loop that crashes the application. The conditions an environment must meet to be abused are extensive — so extensive that the practical severity of the problem is disputed. Despite the patch being officially recommended, not everyone is convinced.
Not every instance of Log4j is vulnerable. Only library applications running on custom settings are at risk. Also, a potential attacker needs a detailed understanding of how Log4j works in a targeted environment. This is a major contrast to the initial, highly accessible vulnerability that was patched with versions 2.14, 2.15 and 2.16.
14 hours ago
