Anyone who works in IT will, by now, be acutely aware of the critical security vulnerability that was revealed in the Log4J library last week. It’s even being reported in mainstream media with headlines like “The internet is on fire!” (Which seems a little unlikely).
The vulnerability is extremely serious, having been given a CVSS of 10.0, the highest possible value. Unfortunately, this means it is a vulnerability that can be exploited quite easily and via a remote connection. I’ve seen several ways of using this vulnerability that only require a particular string to be entered in a web form.
One of the reasons Java is so popular as a development platform is the availability of libraries of classes that provide almost any functionality you can think of. In JDK 17, just the core classes number nearly 8,000, covering everything from basic input-output to handling cryptographic signatures. (It should also be noted that the JDK includes a logging API).
Although the core libraries in the JDK cover a broad range of functionality, there is an unparalleled richness of other libraries, many of which are open-source and free to use. Not reinventing the same wheel each time when creating a new application has great appeal and reduces both the time and cost of developing applications.
However, as we’ve seen, this does not come without risk.
Although, as I mentioned, the JDK provides a logging API, many developers do not see it as powerful enough to handle all the scenarios required for complex enterprise applications. As a result, log4J, an Apache Foundation open source project, has become the defacto standard for recording messages about what an application is doing.
Since logging is fundamental to monitoring and managing enterprise software, it needs to be pervasive in the code used. The impact of this is that, even though the code you’ve written may not make use of Log4J, there is a strong chance other libraries or frameworks you use do. The widely used Apache Struts framework is an excellent example of this.
Fortunately, this vulnerability does not affect the logging library included in OpenJDK. The implication is that not all JVM-based applications are exposed, only those that use Log4J.
For those applications that do use Log4J, it is vital that you update to the latest release of the library. Version 2.15 was released when the vulnerability was made public. This has since been superseded by version 2.16, which addresses a subsequently discovered edge-case vulnerability.
As a more general recommendation, to ensure maximum security for your Java applications, it is best to keep all components, especially the JDK updated with all available patches. Azul’s Platform Core product makes that as simple as possible. Find out more here
