The emergency patch for the infamous vulnerability in Java library Log4j is not foolproof. The Apache Software Foundation is releasing a new version to fix the vulnerability once and for all.
A vulnerability in a wildly popular library for Java is shaking the global IT landscape. It is estimated that the library exists in most corporate environments.
Log4j is mainly used for logging. Events in applications can be registered with notes. Think of a printout of the login details after a login attempt. Or, in the case of a web application in Java, the name of the browser a user is trying to connect to.
The latter examples are common. In both cases, an external user influences the log that Log4j outputs. It is possible to abuse that influence. The logs of any Log4j version between September 13, 2013 and December 5, 2021 are able to instruct Java applications to run the code from a remote server on a local device.
Since 2013, Log4j has been processing an API: JNDI, or Java Naming and Directory Interface. The addition of JNDI allows a Java application to run code from a remote server on a local device. Programmers instruct by adding a single line of details about the remote server in an application.
The problem is that not only programmers are able to add the rule to applications. Suppose Log4j logs the usernames of login attempts. When someone enters the aforementioned line in the username field, Log4j runs the line and the Java application interprets a command to run the code on the specified server. The same goes for cases where Log4j logs an HTTPS request. If you change a browser name to the line, Log4j runs the line, indirectly instructing it to run code as desired.
Emergency patch can also be unsafe
On December 9, the vulnerability came to light on a large scale. The Apache Software Foundation, developer of Log4j, released an emergency patch (2.15) to fix the vulnerability. Since then, it has been a top priority for software vendors to process version 2.15 and provide a patch for organizations.
However, security organization LunaSec states that the patch is not completely watertight. It remains possible to adjust a setting and to have logged JNDI commands executed.
Please note: the relevant setting must be adjusted manually, so that unmodified variants of 2.15 are indeed safe. Nevertheless, Luna Sec recommends that suppliers and organizations update to Log4j 2.16. 2.16 was published by Apache Software Foundation in response to LunaSec. The new version completely removes the vulnerable setting, making it impossible to create the conditions for abuse.
