Skip to content

Why the Java serialization vulnerability makes Heartbleed look tame - explained

    
Why the Java serialization vulnerability makes Heartbleed look tame - explained

I've been receiving questions from some of you to provide a bit more detail on why this Java vulnerability is so critical to fix...

Basically, why is this such a big deal? 

It’s a big deal because many enterprise applications are vulnerable. It’s not fully automated, but it’s still pretty easy to find and exploit this problem in applications.  And it allows the attacker to completely take over the entire server the application is hosted on.  They could steal or corrupt any data accessible from that server, steal the application's code, change the application, or even use that server as a launching point for further attacks now that they are inside the data center.

What exactly is the vulnerability all about?

Programmers use “serialization" to transfer complex data structures between computers. It’s an easy way to take a whole bunch of “objects” and turn them into a single data stream that can be “deserialized” at the other end.   In this attack, special objects are serialized that cause the standard Java deserialization engine to run code of the attacker’s choosing.  It’s not exactly a problem in Java, or in any particular libraries.  It’s just a powerful functionality that organizations shouldn’t expose to untrusted users.

What are the implications for enterprises?

They should immediately find all the places where they are using deserialization on untrusted data, as there is a high likelihood that it is exploitable.  Searching their code is only a partial solution, because frameworks and libraries that they are including in their applications might also create this exposure.

How can it be mitigated?

The deserialization vulnerability is tricky to mitigate because it can occur anywhere in your stack — your app server, framework, libraries, or custom code.  The best way to solve this problem is to use something called Runtime Application Self-Protection (RASP).  You add an agent to your Java environment that hardens everywhere that uses the deserialization engine and prevents it from being exploited.

Jeff Williams, Co-Founder, Chief Technology Officer

Jeff Williams, Co-Founder, Chief Technology Officer

Jeff brings more than 20 years of security leadership experience as co-founder and Chief Technology Officer of Contrast Security. He recently authored the DZone DevSecOps, IAST, and RASP refcards and speaks frequently at conferences including JavaOne (Java Rockstar), BlackHat, QCon, RSA, OWASP, Velocity, and PivotalOne. Jeff is also a founder and major contributor to OWASP, where he served as Global Chairman for 9 years, and created the OWASP Top 10, OWASP Enterprise Security API, OWASP Application Security Verification Standard, XSS Prevention Cheat Sheet, and many more popular open source projects. Jeff has a BA from Virginia, an MA from George Mason, and a JD from Georgetown.