Hello Bernd, nice article and I would be happy to see this on the ASF blog to point people to it.
I also found some typos: "Both research work shows that developers" should be "Both research works show that developers" "final type is checked lot of code" should be "final type is checked a lot of code" "sample payloads which combines classes" should be "sample payloads which combine classes" Timo 2015-11-09 9:36 GMT+01:00 Benedikt Ritter <brit...@apache.org>: > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
