commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timo <>
Subject Re: [COLLECTIONS] Bad press on twitter following serialization issue
Date Mon, 09 Nov 2015 09:18:18 GMT
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"


2015-11-09 9:36 GMT+01:00 Benedikt Ritter <>:
> 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 (
> ).
> Thanks,
> Benedikt
> 2015-11-09 9:16 GMT+01:00 Bernd Eckenfels <>:
>> 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](
>> "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).
>> Build on Frohoff's tool
>> [ysoserial](, Stephen Breen
>> ([@breenmachine]( of Foxglove
>> Security inspected various products like WebSphere, JBoss, Jenkins,
>> WebLogic, and OpenNMS and describes
>> (
>> )
>> 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()](
>> )
>> 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>
>> 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](
>> (
>> )
>> 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
>> 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]( 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).
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> --

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message