Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
MIME-Version: 1.0
Sender: mailantimo@gmail.com
In-Reply-To: 
 <CAB917RL1vOguOsf7-UGfYt5uu1PDtySjuYqpJSCJJuy_F9t8ZQ@mail.gmail.com>
References: 
 <CAB917RKGcjmpJ0fnVvC-iAoSEwOTpjKhEQc93cf9dUAWhQZdrA@mail.gmail.com>
	<CAA_A7u+v47K-STtKhwO2zfjYthdojgET7fqrzt6LPig3SAL-kA@mail.gmail.com>
	<CACZkXPzO4G721_=ZK_zx2k7VCqUC-Wq8stn2NnqiP3cmRdkmFQ@mail.gmail.com>
	<20151108201944.000011a4.ecki@zusammenkunft.net>
	<CACZkXPxAj=OLt5Uy5dEoj=U-B=RZUBFabj-4kipv8rA7cCi_Tg@mail.gmail.com>
	<20151108233817.000067d5.ecki@zusammenkunft.net>
	<CACZkXPwoOWy4+gS7iZAYezYwmbSToE2qkGsj_AfEEqgKd20UQw@mail.gmail.com>
	<20151109091604.00007d74.ecki@zusammenkunft.net>
	<CAB917RL1vOguOsf7-UGfYt5uu1PDtySjuYqpJSCJJuy_F9t8ZQ@mail.gmail.com>
Date: Mon, 9 Nov 2015 10:18:18 +0100
Message-ID: 
 <CAONNSUYO9cZQxzO672Qhm7j962HqoVtgC1+eJLFiXsN4XsEMkQ@mail.gmail.com>
Subject: Re: [COLLECTIONS] Bad press on twitter following serialization issue
From: Timo <MailAnTimo@gmx.de>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=UTF-8

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 <britter@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 (sk@apache.org
> ).
>
> Thanks,
> Benedikt
>
> 2015-11-09 9:16 GMT+01:00 Bernd Eckenfels <ecki@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org