Comment on the so-called security vulnerability in Apache Commons Collections

There has been some fuss about a security vulnerability in the well known Apache Commons Collections library. It was initially described in the talk “Marshalling Pickles – how deserializing objects will ruin your day” at AppSecCali2015 by Gabriel Lawrence (@gebl ) and Chris Frohoff (@frohoff ). The Apache Commons Project published a statement about this vulnerability a few days ago. Since I’ve been asked by several people about this, I think it would be good the give some more information about this. The most important take-away from this blog post is: It is not Apache Commons Collections that is unsafe, it is applications which use Java Serialization in an unsafe way.

No easy fix

Furthermore it is important to understand that replacing or removing Apache Commons Collections from your application or application server is unlikely to make it safer. This is because the attack described by Lawrence and Frohoff can also use classes from other popular libraries like the Spring Framework or Groovy . There is even a class in the JDK that can be used for this attack (com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl). This is bad because “Apache Commons Collections is unsafe” is so much easier an explanation than “an application is unsafe if it uses Java Serialization in an unsafe way”. It’s no fix where you replace the old version of a library with a new version and everything is good. Instead one has to review application code and decide whether is is safe or not.

The attack explained

First of all, let me give you an idea about the attack vector described by Lawrence and Frohoff:
The attacker creates a Map and decorates it with a TransformedMap . He then adds a special implementation of the Transformers interface which use reflection to transform values (see InvokerTransformer ) and instruments it to use reflection to call, for example Runtime.exec(String) . The map is then sent via Java Serialization to the target of the attack. Since in Java Serialization the type of the object being send is also referenced in the binary stream, the target will create new objects from the data in the stream using the classes also included in the stream. If code accesses the deserialized map, the InvokerTransformer will be called and the attack succeeds. This is what security experts call a “gadget chain”.

So far, so good. Let’s recap which conditions an application (*) has to meet in order to be vulnerable to this attack:

• Apache Commons Collections in the classpath – otherwise deserialization would fail
• exposes an endpoint that takes binary data and creates objects without checking their type first
• lets untrustworthy parties access the endpoint without authorization

Again, it’s important to understand that an application isn’t vulnerable because it uses Apache Commons Collections or any of the other libraries that allow for creating similar gadget chains. Applications are vulnerable because they’re deserializing untrusted data without further checking. Because this is so negligent Lawrence and Frohoff didn’t bother to report this directly to the Apache Commons project. Nevertheless the Apache Commons Project has already released a bugfix for Apache Commons Collections 3.x that has deserialization for the InvokerTransformer disabled by default (it can be reactivated explicitly using a system property).
Furthermore, there is a discussion about adding a SafeObjectInputStream to Apache Commons IO that let’s you specify classes that may be deserialized, if you really need to use Java Serialization to communicate with remotes. All other classes will be rejected before deserialization.

Please be fair

So, why am I writing all this? I don’t like the bad press and finger pointing at Apache Commons, because this is clearly not a problem with Commons Collections but with the way serialization in Java works. There are people putting a lot of energy and free time into maintaining projects like Apache Commons, Spring or Groovy. They are of great use for the Java community. I think they deserve to be treated fairly. So please help me stop this madness! If anybody asks you whether an application is unsafe because of Apache Commons Collections, explain to them that deserializing untrusted data is unsafe, not the presence of generally useful libraries.

Thank you!

(*) Note that I’m not only talking about EAR’s or WAR’s but also about the application servers they’re running in.