The emergency patch for the infamous vulnerability in Java library Log4j is not foolproof. Its developer, Apache Software Foundation, publishes a new version (2.16) in hopes of eliminating the vulnerability once and for all.
A severe vulnerability in an extremely popular Java library puts the global IT landscape on edge. The library is estimated to be found in most corporate environments.
Log4j is primarily used for logging. Events in applications can be recorded with notes. Think of a printout of the login information after a login attempt. Or, in the case of a web application, the name of the browser a user is trying to connect through.
In both cases, an external user influences the log that Log4j prints out. It is possible to abuse that influence. The logs of every Log4j version between September 13, 2013 and December 5, 2021 can instruct Java applications to execute code from a remote server on a local device.
Since 2013, Log4j has incorporated an API: JNDI, short for Java Naming and Directory Interface. The addition of JNDI enables a Java application to execute code from a remote server on a local device. Programmers issue the instruction by adding a single string with information about the remote server to an application.
The problem is that not only programmers are able to add the string to applications. Suppose Log4j logs the usernames of login attempts. If someone enters the string in the username field, Log4j prints the string, and the Java application interprets a command to execute the code on the specified server. The same goes for cases where Log4j logs a HTTPS request. Changing a browser name to the string prompts Log4j to print and indirectly instruct the application to execute code of choosing.
Emergency patch is not foolproof
On December 9, the vulnerability was widely exposed. Apache Software Foundation, the developer of Log4j, published an emergency patch (2.15) to resolve the vulnerability. Since then, it has been a top priority for software vendors to process version 2.15 in their software and provide a safe update to their user base.
One problem, says security organization LunaSec. The patch is not entirely foolproof. It remains possible to adjust a setting and have logged JNDI strings executed.
Note that the setting in question must be changed manually, which means that unmodified variants of 2.15 are safe. Nevertheless, Luna Sec recommends that vendors and organizations update to Log4j 2.16.
2.16 was published by Apache Software Foundation in response to LunaSec. The new version completely eliminates the vulnerable setting, making it impossible to create the conditions for abuse.
Tip: 60 variations of Log4Shell, hundreds of thousands of attacks
4 hours ago
