Fixing Java Serialization Bugs with SerialKiller

On Friday, FoxGloveSecurity published a rather inaccurate and misleading blog post on five software vulnerabilities affecting WebLogic, WebSphere, JBoss, Jenkins and OpenNMS. By incorrectly attributing the vulnerability to the Apache Commons Collection library, the blog post generated misinformation on the root cause and possible fixes (e.g. this news.softpedia article).


If you're still unsure on what is the actual issue, Charles Miller published a short blog post illustrating the problem.

Probably thinking that the Apache project wasn't interested in fixing the bug, FoxGloveSecurity's post also contains working exploits for all products.

In fact, even though proof of concept code was released OVER 9 MONTHS AGO, none of the products mentioned in the title of this post have been patched, along with many more. In fact no patch is available for the Java library containing the vulnerability.

As it turned out, some vendors were not aware and others were already working on a patch in their products but haven't released it yet.

Summing up, we're now dealing with five pre-authentication remote code execution vulnerabilities affecting major products. Luckily, the specific services affected by those vulnerabilities are generally not exposed over the Internet thus reducing the overall risk.

Inspired by this story, I started thinking on how I could fix the problem in a systematic way. It didn't take me long to discover this article on using method override to create a look-ahead deserialization filter. While the article explains a potential solution, it didn't provide an easy-to-use library that can be used to protect Java applications.

Introducing SerialKiller

SerialKiller is an easy-to-use look-ahead Java deserialization library to secure applications from untrusted input. You drop the jar in your classpath, use SerialKiller instead of the standard java.io.ObjectInputStream and configure it to allow/block specific classes.


The library, together with a simple tutorial, is available on Github:
https://github.com/ikkisoft/SerialKiller

At the moment, it supports the following features:

  • Hot-Reload for the config file, so that you don't need to restart your application after changing SerialKiller's config
  • Whitelisting.  If you can quickly identify a list of trusted classes, this is the best way to secure your application. For instance, you could allow classes belonging to your application package only
  • Blacklisting. The default config file already includes a few known attack payloads (thanks to YSoSerial). This can be used to block the exploits released by FoxGloveSecurity

If you want to contribute, ping me on Twitter or using Github.




1 comments:

  jwilliams

November 14, 2015 at 7:10 PM

We just released a different solution to this problem. It's free and open source. Contrast-rO0 is a lightweight Java agent that uses instrumentation to block attacks targeting object deserialization problems like those described above.

This approach is the only way to protect your *entire* application because the problem can exist in libraries or frameworks. Rather than re-architecting your entire messaging infrastructure, this agent absolutely prevents this vulnerability from being exploited.

https://github.com/Contrast-Security-OSS/contrast-rO0