You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Benedikt Ritter <br...@apache.org> on 2015/11/08 10:41:59 UTC
[COLLECTIONS] Bad press on twitter following serialization issue
Hi,
there is a lot of bad talk going on at twitter [1,2,3] and I'm wondering
whether we should respond to this via the Apache blog.
Thoughts?
Benedikt
[1] https://twitter.com/JustineTunney/status/662937508980723712
[2] https://twitter.com/kennwhite/status/662709833464872960
[3] https://twitter.com/jodastephen/status/663253106751180800
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [COLLECTIONS] Bad press on twitter following serialization
issue
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Hello Gary,
thanks for the offer. I will sent you a edit-link for the article, here
is a comment-only version for people to check:
https://oasis.sandstorm.io/shared/prUMi3zkPMx9bdQ8X2vkX7nt7JW79G3b28IKhS_F8vQ
Greetings
Bernd
Am Sun, 8 Nov 2015
12:20:55 -0800 schrieb Gary Gregory <ga...@gmail.com>:
> Sounds good. I'll be happy to edit if you'd like.
>
> Gary
>
> On Sun, Nov 8, 2015 at 11:19 AM, Bernd Eckenfels
> <ec...@zusammenkunft.net> wrote:
>
> > Hello Gary,
> >
> > if we can release a fixed version quickly I would agree, but it is
> > not really needed for a reply to the ongoing FUD.
> >
> > A statement would be "the dicovered vulnerability is in applications
> > using JavaObject serialisation from untrusted sources and not
> > implementing additional precaution like whitelists or restricted
> > classloaders, it is not in one of the many example classes used by
> > the POC exploits. Neighter Spring, Groovy or Apache Commons are
> > responsible for the security bug.
> >
> > Even tough, Apache Commons plans to add some infrastructure for
> > restricting the currently most often used class for "gadget chains"
> > to not suport de-serialisationby default. This will be provided for
> > 3.2 and 4.0 branches (with an programmatic and system property
> > option to turn the old behavior back on)"
> >
> > I havent blogged on the ASF blogs yet, but I would be willing to
> > write on a text like that.
> >
> > Gruss
> > Bernd
> >
> >
> > Am Sun, 8 Nov 2015
> > 10:22:12 -0800 schrieb Gary Gregory <ga...@gmail.com>:
> >
> > > Hi All:
> > >
> > > What about agreeing on a plan before we post anything? My proposal
> > > would be to follow up on an idea posted on the dev ML: Use a
> > > system property to enable the risky feature. This would change
> > > the default behavior to disallow the feature. And possibly add a
> > > new config option on the problematic class to control the behavior
> > > programatically. If the prog config would override the sys prop.
> > > We can release a 3.x and 4.x version once we agree on a plan and
> > > then blog about it again.
> > >
> > > Thoughts?
> > >
> > > Gary
> > >
> > > On Sun, Nov 8, 2015 at 10:10 AM, Gabriel Lawrence <
> > > gabriel.lawrence@gmail.com> wrote:
> > >
> > > > If you guys want to put together a blog post about this, Chris
> > > > and I would be happy to help. We've tried to be pretty clear to
> > > > people that this isnt a problem with the libraries, but
> > > > something that should be addressed by the deserializer either
> > > > by not deserializing from a trusted source or by hacking in
> > > > their own way to whitelist types allowed to be deserialized.
> > > >
> > > > I think the core message is that object instantiation is code
> > > > execution, don't give untrusted folks the ability to instantiate
> > > > arbitrary objects or you are going to have a bad day. Pulling
> > > > together gadgets is a painful search, but the idea that you can
> > > > find them all and eliminate them seems flawed. There are likely
> > > > going to be things in your classpath that do stuff similar to
> > > > the set of gadgets Chris found that rely on the apache library
> > > > in tuns of other class libraries as well.
> > > >
> > > > Let us know. Since this broke out on twitter we've both been
> > > > trying hard to get the description of the root of the problem
> > > > to be changed. But, it seems to have stuck for some reason...
> > > > maybe because having it be a simple fix is just more desirable
> > > > to people :-) Even when it isn't.
> > > >
> > > > gabe
> > > >
> > > > On Sun, Nov 8, 2015 at 1:41 AM, Benedikt Ritter
> > > > <br...@apache.org> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > there is a lot of bad talk going on at twitter [1,2,3] and I'm
> > > > > wondering whether we should respond to this via the Apache
> > > > > blog.
> > > > >
> > > > > Thoughts?
> > > > > Benedikt
> > > > >
> > > > > [1]
> > > > > https://twitter.com/JustineTunney/status/662937508980723712
> > > > > [2] https://twitter.com/kennwhite/status/662709833464872960
> > > > > [3] https://twitter.com/jodastephen/status/663253106751180800
> > > > >
> > > > >
> > > > > --
> > > > > 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
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [COLLECTIONS] Bad press on twitter following serialization
issue
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Am Mon, 9 Nov 2015 09:36:41 +0100
schrieb Benedikt Ritter <br...@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
fixed
> "However it should be clear, this is not the only known (and
> especially not yet know) gadget" - should be "and especially not yet
> known"
reworded:
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [COLLECTIONS] Bad press on twitter following serialization
issue
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Thanks Timo!
Am Mon, 9 Nov 2015 10:18:18 +0100
schrieb Timo <Ma...@gmx.de>:
> 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"
fixed.
>
> "final type is checked lot of code"
> should be
> "final type is checked a lot of code"
fixed.
> "sample payloads which combines classes"
> should be
> "sample payloads which combine classes"
fixed.
So here is the version with the reviews from Timo and Ben added:
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [COLLECTIONS] Bad press on twitter following serialization issue
Posted by Timo <Ma...@gmx.de>.
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 <br...@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 <ec...@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
Re: [COLLECTIONS] Bad press on twitter following serialization issue
Posted by Benedikt Ritter <br...@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 <ec...@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
Re: [COLLECTIONS] Bad press on twitter following serialization
issue
Posted by Bernd Eckenfels <ec...@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
Re: [COLLECTIONS] Bad press on twitter following serialization issue
Posted by Gary Gregory <ga...@gmail.com>.
Sounds good. I'll be happy to edit if you'd like.
Gary
On Sun, Nov 8, 2015 at 11:19 AM, Bernd Eckenfels <ec...@zusammenkunft.net>
wrote:
> Hello Gary,
>
> if we can release a fixed version quickly I would agree, but it is not
> really needed for a reply to the ongoing FUD.
>
> A statement would be "the dicovered vulnerability is in applications
> using JavaObject serialisation from untrusted sources and not
> implementing additional precaution like whitelists or restricted
> classloaders, it is not in one of the many example classes used by the
> POC exploits. Neighter Spring, Groovy or Apache Commons are responsible
> for the security bug.
>
> Even tough, Apache Commons plans to add some infrastructure for
> restricting the currently most often used class for "gadget chains" to
> not suport de-serialisationby default. This will be provided for 3.2
> and 4.0 branches (with an programmatic and system property option
> to turn the old behavior back on)"
>
> I havent blogged on the ASF blogs yet, but I would be willing to write
> on a text like that.
>
> Gruss
> Bernd
>
>
> Am Sun, 8 Nov 2015
> 10:22:12 -0800 schrieb Gary Gregory <ga...@gmail.com>:
>
> > Hi All:
> >
> > What about agreeing on a plan before we post anything? My proposal
> > would be to follow up on an idea posted on the dev ML: Use a system
> > property to enable the risky feature. This would change the default
> > behavior to disallow the feature. And possibly add a new config
> > option on the problematic class to control the behavior
> > programatically. If the prog config would override the sys prop. We
> > can release a 3.x and 4.x version once we agree on a plan and then
> > blog about it again.
> >
> > Thoughts?
> >
> > Gary
> >
> > On Sun, Nov 8, 2015 at 10:10 AM, Gabriel Lawrence <
> > gabriel.lawrence@gmail.com> wrote:
> >
> > > If you guys want to put together a blog post about this, Chris and
> > > I would be happy to help. We've tried to be pretty clear to people
> > > that this isnt a problem with the libraries, but something that
> > > should be addressed by the deserializer either by not deserializing
> > > from a trusted source or by hacking in their own way to whitelist
> > > types allowed to be deserialized.
> > >
> > > I think the core message is that object instantiation is code
> > > execution, don't give untrusted folks the ability to instantiate
> > > arbitrary objects or you are going to have a bad day. Pulling
> > > together gadgets is a painful search, but the idea that you can
> > > find them all and eliminate them seems flawed. There are likely
> > > going to be things in your classpath that do stuff similar to the
> > > set of gadgets Chris found that rely on the apache library in tuns
> > > of other class libraries as well.
> > >
> > > Let us know. Since this broke out on twitter we've both been trying
> > > hard to get the description of the root of the problem to be
> > > changed. But, it seems to have stuck for some reason... maybe
> > > because having it be a simple fix is just more desirable to
> > > people :-) Even when it isn't.
> > >
> > > gabe
> > >
> > > On Sun, Nov 8, 2015 at 1:41 AM, Benedikt Ritter <br...@apache.org>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > there is a lot of bad talk going on at twitter [1,2,3] and I'm
> > > > wondering whether we should respond to this via the Apache blog.
> > > >
> > > > Thoughts?
> > > > Benedikt
> > > >
> > > > [1] https://twitter.com/JustineTunney/status/662937508980723712
> > > > [2] https://twitter.com/kennwhite/status/662709833464872960
> > > > [3] https://twitter.com/jodastephen/status/663253106751180800
> > > >
> > > >
> > > > --
> > > > 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
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [COLLECTIONS] Bad press on twitter following serialization
issue
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Hello Gary,
if we can release a fixed version quickly I would agree, but it is not
really needed for a reply to the ongoing FUD.
A statement would be "the dicovered vulnerability is in applications
using JavaObject serialisation from untrusted sources and not
implementing additional precaution like whitelists or restricted
classloaders, it is not in one of the many example classes used by the
POC exploits. Neighter Spring, Groovy or Apache Commons are responsible
for the security bug.
Even tough, Apache Commons plans to add some infrastructure for
restricting the currently most often used class for "gadget chains" to
not suport de-serialisationby default. This will be provided for 3.2
and 4.0 branches (with an programmatic and system property option
to turn the old behavior back on)"
I havent blogged on the ASF blogs yet, but I would be willing to write
on a text like that.
Gruss
Bernd
Am Sun, 8 Nov 2015
10:22:12 -0800 schrieb Gary Gregory <ga...@gmail.com>:
> Hi All:
>
> What about agreeing on a plan before we post anything? My proposal
> would be to follow up on an idea posted on the dev ML: Use a system
> property to enable the risky feature. This would change the default
> behavior to disallow the feature. And possibly add a new config
> option on the problematic class to control the behavior
> programatically. If the prog config would override the sys prop. We
> can release a 3.x and 4.x version once we agree on a plan and then
> blog about it again.
>
> Thoughts?
>
> Gary
>
> On Sun, Nov 8, 2015 at 10:10 AM, Gabriel Lawrence <
> gabriel.lawrence@gmail.com> wrote:
>
> > If you guys want to put together a blog post about this, Chris and
> > I would be happy to help. We've tried to be pretty clear to people
> > that this isnt a problem with the libraries, but something that
> > should be addressed by the deserializer either by not deserializing
> > from a trusted source or by hacking in their own way to whitelist
> > types allowed to be deserialized.
> >
> > I think the core message is that object instantiation is code
> > execution, don't give untrusted folks the ability to instantiate
> > arbitrary objects or you are going to have a bad day. Pulling
> > together gadgets is a painful search, but the idea that you can
> > find them all and eliminate them seems flawed. There are likely
> > going to be things in your classpath that do stuff similar to the
> > set of gadgets Chris found that rely on the apache library in tuns
> > of other class libraries as well.
> >
> > Let us know. Since this broke out on twitter we've both been trying
> > hard to get the description of the root of the problem to be
> > changed. But, it seems to have stuck for some reason... maybe
> > because having it be a simple fix is just more desirable to
> > people :-) Even when it isn't.
> >
> > gabe
> >
> > On Sun, Nov 8, 2015 at 1:41 AM, Benedikt Ritter <br...@apache.org>
> > wrote:
> >
> > > Hi,
> > >
> > > there is a lot of bad talk going on at twitter [1,2,3] and I'm
> > > wondering whether we should respond to this via the Apache blog.
> > >
> > > Thoughts?
> > > Benedikt
> > >
> > > [1] https://twitter.com/JustineTunney/status/662937508980723712
> > > [2] https://twitter.com/kennwhite/status/662709833464872960
> > > [3] https://twitter.com/jodastephen/status/663253106751180800
> > >
> > >
> > > --
> > > 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
Re: [COLLECTIONS] Bad press on twitter following serialization issue
Posted by Gary Gregory <ga...@gmail.com>.
Hi All:
What about agreeing on a plan before we post anything? My proposal would be
to follow up on an idea posted on the dev ML: Use a system property to
enable the risky feature. This would change the default behavior to
disallow the feature. And possibly add a new config option on the
problematic class to control the behavior programatically. If the prog
config would override the sys prop. We can release a 3.x and 4.x version
once we agree on a plan and then blog about it again.
Thoughts?
Gary
On Sun, Nov 8, 2015 at 10:10 AM, Gabriel Lawrence <
gabriel.lawrence@gmail.com> wrote:
> If you guys want to put together a blog post about this, Chris and I would
> be happy to help. We've tried to be pretty clear to people that this isnt a
> problem with the libraries, but something that should be addressed by the
> deserializer either by not deserializing from a trusted source or by
> hacking in their own way to whitelist types allowed to be deserialized.
>
> I think the core message is that object instantiation is code execution,
> don't give untrusted folks the ability to instantiate arbitrary objects or
> you are going to have a bad day. Pulling together gadgets is a painful
> search, but the idea that you can find them all and eliminate them seems
> flawed. There are likely going to be things in your classpath that do stuff
> similar to the set of gadgets Chris found that rely on the apache library
> in tuns of other class libraries as well.
>
> Let us know. Since this broke out on twitter we've both been trying hard to
> get the description of the root of the problem to be changed. But, it seems
> to have stuck for some reason... maybe because having it be a simple fix is
> just more desirable to people :-) Even when it isn't.
>
> gabe
>
> On Sun, Nov 8, 2015 at 1:41 AM, Benedikt Ritter <br...@apache.org>
> wrote:
>
> > Hi,
> >
> > there is a lot of bad talk going on at twitter [1,2,3] and I'm wondering
> > whether we should respond to this via the Apache blog.
> >
> > Thoughts?
> > Benedikt
> >
> > [1] https://twitter.com/JustineTunney/status/662937508980723712
> > [2] https://twitter.com/kennwhite/status/662709833464872960
> > [3] https://twitter.com/jodastephen/status/663253106751180800
> >
> >
> > --
> > http://people.apache.org/~britter/
> > http://www.systemoutprintln.de/
> > http://twitter.com/BenediktRitter
> > http://github.com/britter
> >
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [COLLECTIONS] Bad press on twitter following serialization issue
Posted by Gabriel Lawrence <ga...@gmail.com>.
If you guys want to put together a blog post about this, Chris and I would
be happy to help. We've tried to be pretty clear to people that this isnt a
problem with the libraries, but something that should be addressed by the
deserializer either by not deserializing from a trusted source or by
hacking in their own way to whitelist types allowed to be deserialized.
I think the core message is that object instantiation is code execution,
don't give untrusted folks the ability to instantiate arbitrary objects or
you are going to have a bad day. Pulling together gadgets is a painful
search, but the idea that you can find them all and eliminate them seems
flawed. There are likely going to be things in your classpath that do stuff
similar to the set of gadgets Chris found that rely on the apache library
in tuns of other class libraries as well.
Let us know. Since this broke out on twitter we've both been trying hard to
get the description of the root of the problem to be changed. But, it seems
to have stuck for some reason... maybe because having it be a simple fix is
just more desirable to people :-) Even when it isn't.
gabe
On Sun, Nov 8, 2015 at 1:41 AM, Benedikt Ritter <br...@apache.org> wrote:
> Hi,
>
> there is a lot of bad talk going on at twitter [1,2,3] and I'm wondering
> whether we should respond to this via the Apache blog.
>
> Thoughts?
> Benedikt
>
> [1] https://twitter.com/JustineTunney/status/662937508980723712
> [2] https://twitter.com/kennwhite/status/662709833464872960
> [3] https://twitter.com/jodastephen/status/663253106751180800
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
Re: [COLLECTIONS] Bad press on twitter following serialization issue
Posted by Gary Gregory <ga...@gmail.com>.
I think I saw a /. article about this yesterday... yikes.
G
On Wed, Nov 11, 2015 at 12:30 AM, Bernd Eckenfels <ec...@zusammenkunft.net>
wrote:
> Hello,
>
> BTW Oracle issued a "Strange" Security alert:
>
> 2015-4852 was released on November 10th, 2015.
>
> This vulnerability, which involves the Apache Commons and Oracle WebLogic
> Server, has received a CVSS Base Score of 7.5.
> ...
>
> Bernd
>
> > Am 08.11.2015 um 10:41 schrieb Benedikt Ritter <br...@apache.org>:
> >
> > Hi,
> >
> > there is a lot of bad talk going on at twitter [1,2,3] and I'm wondering
> > whether we should respond to this via the Apache blog.
> >
> > Thoughts?
> > Benedikt
> >
> > [1] https://twitter.com/JustineTunney/status/662937508980723712
> > [2] https://twitter.com/kennwhite/status/662709833464872960
> > [3] https://twitter.com/jodastephen/status/663253106751180800
> >
> >
> > --
> > 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
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [COLLECTIONS] Bad press on twitter following serialization issue
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Hello,
BTW Oracle issued a "Strange" Security alert:
2015-4852 was released on November 10th, 2015.
This vulnerability, which involves the Apache Commons and Oracle WebLogic Server, has received a CVSS Base Score of 7.5.
...
Bernd
> Am 08.11.2015 um 10:41 schrieb Benedikt Ritter <br...@apache.org>:
>
> Hi,
>
> there is a lot of bad talk going on at twitter [1,2,3] and I'm wondering
> whether we should respond to this via the Apache blog.
>
> Thoughts?
> Benedikt
>
> [1] https://twitter.com/JustineTunney/status/662937508980723712
> [2] https://twitter.com/kennwhite/status/662709833464872960
> [3] https://twitter.com/jodastephen/status/663253106751180800
>
>
> --
> 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