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





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.

pre-authentication remote code execution vulnerabilities

Introducing SerialKiller

Hot-Reload for the config file, so that you don't need to restart your application after changing SerialKiller's config

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

. If you can quickly identify a list of trusted classes, this is the 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'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.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 fiveaffecting 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. 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 standardand configure it to allow/block specific classes.The library, together with a simple tutorial, is available on Github:At the moment, it supports the following features: