Using Java? This is The Next Heartbleed You Should Be Worried About

December 10, 2015 Patricia Johnson

If you run a Java-based application, you might be at risk. Earlier this year in January, 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.”

We help you secure your open source components – download this guide to see how

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. WhiteSource 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.

Know about next one ahead of time: Integrate our open source management solution to your CI process today.

 

Previous Article
The Engineering VP’s 4-Step Guide To Hiring New Subcontractors
The Engineering VP’s 4-Step Guide To Hiring New Subcontractors

The occasional work overloads are not uncommon, especially not to software development teams. If you’ve eve...

Next Video
How to install the Gradle plugin
How to install the Gradle plugin