The Apache Software Foundation Blog

Tuesday November 10, 2015

Apache Commons statement to widespread Java object de-serialisation vulnerability

Authors: Bernd Eckenfels, Committer, and Gary Gregory, Vice President of Apache Commons

In their talk "Marshalling Pickles - how deserializing objects will ruin your day" at AppSecCali2015 Gabriel Lawrence (@gebl) and Chris Frohoff (@frohoff) presented various security problems when applications accept serialized objects from untrusted source. A major finding describes a way to execute arbitrary Java functions and even inject manipulated bytecode when using Java Object Serialization (as used in some remote communication and persistence protocols).

Building on Frohoff's tool ysoserial, Stephen Breen (@breenmachine) of Foxglove Security inspected various products like WebSphere, JBoss, Jenkins, WebLogic, and OpenNMS and describes (http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/) for each of them various attack scenarios.

Both research works show that developers put too much trust in Java Object Serialization. Some even de-serialize objects pre-authentication. When deserializing an Object in Java you typically cast it to an expected type, and therefore Java's strict type system will ensure you only get valid object trees. Unfortunately, by the time the type checking happens, platform code has already created and executed significant logic. So, before the final type is checked a lot of code is executed from the readObject() methods of various objects, all of which is out of the developer's control. By combining the readObject() methods of various classes which are available on the classpath of the vulnerable application an attacker can execute functions (including calling Runtime.exec() to execute local OS commands).

The best protection against this, is to avoid using a complex serialization protocol with untrusted peers. It is possible to limit the impact when using a custom ObjectInputStream which overrides resolveClass to implement a whitelist approach http://www.ibm.com/developerworks/library/se-lookahead/. This might however not always be possible, such as when a framework or application server provides the endpoint. This is rather bad news, as there is no easy fix and applications need to revisit their client-server protocols and overall architecture.

In these rather unfortunate situations, people have looked at the sample exploits. Frohoff provided "gadget chains" in sample payloads which combine classes from the Groovy runtime, Spring framework or Apache Commons Collection. It is quite certain that you can combine more classes to exploit this weakness, but those are the chains readily available to attackers today.


screenshot-commons.jpg

Even when the classes implementing a certain functionality cannot be blamed for this vulnerability, and fixing the known cases will also not make the usage of serialization in an untrusted context safe, there is still demand to fix at least the known cases, even when this will only start a Whack-a-Mole game. In fact, it is for this reason the original
team did not think it is necessary to alert the Apache Commons team, hence work has begun relatively late. The Apache Commons team is using the ticket COLLECTION-580
(http://svn.apache.org/viewvc/commons/proper/collections/branches/COLLECTIONS_3_2_X/src/java/org/apache/commons/collections/functors/InvokerTransformer.java?r1=1713136&r2=1713307&pathrev=1713307&diff_format=h) to address the issue in the 3.2 and 4.0 branches of commons-collection by disabling de-serialization of the class InvokerTransformer. A to-do item being discussed is whether to provide programmatic enabling of the feature on a per-transformer basis.

There is some precendence for this, the class com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl which is part of Oracle and OpenJDK JREs and which allows to inject and run
bytecode, does reject deserialization if a security manager is defined. This can be turned off with the system property jdk.xml.enableTemplatesImplDeserialization=true. Apache Commons Collection plans to disable this functionality independent of the existence of a security manager, as this execution model is less commonly used than it should.

However, to be clear: this is not the only known and especially not unknown useable gadget. So replacing your installations with a hardened version of Apache Commons Collections will not make your application resist this vulnerability.

We want to thank Gabriel Lawrence for reviewing this blog post. 

Apache Commons Collection is a Java library offering additional collection classes in addition to the Java Collection framework. The InvokerTransformer is one specific implementation of the Transformer functional interface which can be used to transform objects in a collection (specifically by calling a method via reflection invocation).

Comments:

Oracle has issued a security alert for Weblogic: http://www.oracle.com/technetwork/topics/security/alert-cve-2015-4852-2763333.html?evite=WWSU12091612MPP001 The mitigtion they offer is disabling access to T3 protocol (and filtering T3 methods in the reverse proxies).

Posted by Bernd on November 11, 2015 at 09:29 AM GMT #

The JDK change is not precendence for this. Disabling of the XSLT Template object deserialization was not done to stop these particular exploits but rather to fix a vulnerability that when coupled with other vulnerabilities could be used to bypass the Java sandbox. The Template would let you load bytecode that could load classes from protected packages. It is not possible to use XSLT Template to do something bad purely from deserialization. You need to be able to execute methods on the template and if you can execute methods on the template during deserialization then you probably don't need the XSLT Template object in order to execute code. Gowdiak has a write up of the exploit here: http://www.security-explorations.com/materials/SE-2012-01-ORACLE-8.pdf You can download the PoCs here: http://www.security-explorations.com/materials/se-2012-01-50-60.zip

Posted by Ben on November 12, 2015 at 11:11 AM GMT #

As far as I'm concerned the readObject implementation in question is very far away from what I'd consider in line with its API documentation and intention - populating an object's state from a stream. Having substantial side effects goes beyond this assumed purpose and makes serialization exploitable beyond denial of service.

Posted by Marco on November 12, 2015 at 11:19 PM GMT #

Great post! Will - despite that not being a vulnerability - a unique CVE-ID be assigned (as a unique reference to the "hardened version of Apache Commons Collections")?

Posted by Gsunde on November 13, 2015 at 10:06 PM GMT #

The advice for a defence on this vulnerability is to whitelist classloading in object deserialisation. It seems not to be possible to override resolveClass in the ObjectInputStream used by an RMI server, but by implementing a RMIClassLoaderSpi that applies a whitelist to all classes you can apply a filter. I have implemented this idea, see my project on github: https://github.com/Servoy/rmi-whitelist . I wonder if this implementation is a safe defence.

Posted by Rob Gansevles on November 14, 2015 at 09:22 PM GMT #

"The best protection against this, is to avoid using a complex serialization protocol with untrusted peers." In the context of the paragraph preceding this statement, doesn't this imply that trusted peers should be allowed to execute local OS commands?

Posted by Tim Maletic on November 15, 2015 at 03:48 PM GMT #

Post a Comment:
Comments are closed for this entry.

Calendar

Search

Hot Blogs (today's hits)

Tag Cloud

Categories

Feeds

Links

Navigation