Using Java? This is The Next Heartbleed You Should Be Worried About
Table of Contents
If you run a Java-based application, you might be at risk. In January 2015, Gabriel Lawrence and Chris Frohoff discovered what might turn out to be Java’s Heartbleed — a vulnerability that stems from unsafe deserialization of Java objects. When the vulnerability was announced at the AppSecCal2015, it didn’t get a lot of coverage. Even when Oracle released a CVE in June, it did not get a lot of attraction, but when the team at the FoxGlove Security demonstrated how several Java-based applications like Oracle WebLogic, IBM WebSphere, RedHat JBoss, Jenkins, OpenNMS, and others were vulnerable, the open source community started to take notice.
Java’s remote code execution bug is yet to get a name, but is stated to be a highly severe bug with an exploitability score of 10.
The Vulnerability
The vulnerability exists in Apache Commons Collections library (all 3.X releases and the 4.0 release are affected) and originates from unsafe deserialization of Java objects. It’s possible to make a program accept unsafe, user provided serialized data, and this is at the crux of the vulnerability. The discovered bug exploits a remote code execution hole that makes it possible for remote attackers to execute arbitrary commands through a crafted serialized Java object. Stephen Breen posted a very detailed blog post, where he explains how this vulnerability can be exploited in various products, like WebLogic, WebSphere, JBoss, Jenkins and OpenNMS.
The Fix
Apache released a patch a few days ago. Thomas Neidhart, a developer from Apache Commons explained the solution, “We introduced a new system that controls whether the InvokerTransformer can be serialized or not. The default would be false, thus using the new version of the library will mean that any attempt to deserialize an InvokerTransformer will result in an exception.”
The Challenge
To make matters worse, fixing this vulnerability is not that easy. Unlike OpenSSL which runs as a shared library, in Java every application server comes with its own bundle of libraries and every application you deploy on the server often comes with its own set as well. This means that in order to fix this completely, you need to find and update every single library individually.
The Takeaway
This is yet another example showing how important it is for commercial software companies to automatically track discovered security vulnerabilities and software bugs in open source libraries. Mend alerted its customers in real-time when this vulnerability was discovered and also when the patch got released.
If you still trust manual methods of open source tracking, it could be possible that you don’t come to know about such issues at all, at least not until damage is done. You never know, before a vulnerability or a bug makes it big in the headlines or in the open source PR circles, it could be that you might have already put a significant number of your users at risk.
Just like the manual methods of tracking, scanning codes too isn’t efficient.
When such high-severity security issues are discovered, you should try to be alerted in real-time. That’s the only way to stay proactive and respond immediately.
