Hello Bernd, very nice. I found two typos:
"It is possible to limit the impact when using a custom ObjecrtInputStream which overwrites" - should be ObjectInputStream "However it should be clear, this is not the only known (and especially not yet know) gadget" - should be "and especially not yet known" I think we can bring this to the ASF Blog via Sally Khudairi (s...@apache.org ). Thanks, Benedikt 2015-11-09 9:16 GMT+01:00 Bernd Eckenfels <e...@zusammenkunft.net>: > Hello, > > attached is the draft, thanks for Gary and Gabriel (did I miss any > contribution?) > > I think "Bernd Eckenfels and Gary Gregory for Apache Commons" would be > the author (includes a thanks to Gabriel at the end). > > What is the procedure to get this published? > > Title? "Apache Commons statement to widespread Javaobject > de-serialisation vulnerability"? > > > 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 work 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 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 ObjecrtInputStream 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 combines 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 it should be clear, this is not the only known (and especially > not yet know) 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 > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
