It's commons collections On Mon, Nov 9, 2015 at 5:45 AM Bernd Eckenfels <e...@zusammenkunft.net> wrote:
> Hello Sally, > > currently there is a security vulnerability doing the rounds which uses > as an example Apache Commons Collection. It is not really a bug in > Commons Collection, but there is a lot of fuzz. So since we are doing > somethign in the Apache Commons team against the problem we wanted to > make a public statement. > > Here is a blog post, which was discussed on the developer mailinglist. > What is needed to get it published via ASF blogs? (i.e. do you need a > PMC vote or similiar?) > > The syntax for links is markdown, you might have to replace them (so > the links are hidden). Let me know if you have some suggestions for > improvement. > > Greetings > Bernd (e...@apache.org) > > > --- > Apache Commons statement to widespread Java object de-serialisation > vulnerability > > Authors: Bernd Eckenfels, Gary Grogory for Apache Commons > > In their > [talk](http://frohoff.github.io/appseccali-marshalling-pickles/) > "Marshalling Pickles - how deserializing objects will ruin your day" at > AppSecCali2015 Gabriel Lawrence ([@gebl](https://twitter.com/gebl)) and > Chris Frohoff ([@frohoff](https://twitter.com/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). > > Build on Frohoff's tool > [ysoserial](https://github.com/frohoff/ysoserial), Stephen Breen > ([@breenmachine](https://twitter.com/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 shows 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 overwrites > [resolveClass()]( > http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html#resolveClass%28java.io.ObjectStreamClass%29 > ) > to implement a whitelist approach. This might however not always be > possible, 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 Groovy runtime, Sprint 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 https://twitter.com/gebl/status/662786601425080320> > > 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](https://issues.apache.org/jira/browse/COLLECTIONS-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 > unknow 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](https://commons.apache.org/proper/commons-collections/) is > a Java library offering additional collection classes in addition to > the Java Collection framework. The > [InvokerTransformer]( > https://commons.apache.org/proper/commons-collections/javadocs/api-release/org/apache/commons/collections4/functors/InvokerTransformer.html > ) > 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). > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
