You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@commons.apache.org by Bernd Eckenfels <ec...@zusammenkunft.net> on 2015/11/09 11:45:13 UTC

Blog post "commons" vulnerability

Hello Sally,

currently there is a security vulnerability doing the rounds which uses
as an example Apache Commons Collection. It is not really a bug in
Commons Collection, but there is a lot of fuzz. So since we are doing
somethign in the Apache Commons team against the problem we wanted to
make a public statement.

Here is a blog post, which was discussed on the developer mailinglist.
What is needed to get it published via ASF blogs? (i.e. do you need a
PMC vote or similiar?)

The syntax for links is markdown, you might have to replace them (so
the links are hidden). Let me know if you have some suggestions for
improvement.

Greetings
Bernd (ecki@apache.org)

---
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.

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: Blog post "commons" vulnerability

Posted by James Carman <ja...@carmanconsulting.com>.

It's commons collections

On Mon, Nov 9, 2015 at 5:45 AM Bernd Eckenfels <ec...@zusammenkunft.net>
wrote:

> Hello Sally,
>
> currently there is a security vulnerability doing the rounds which uses
> as an example Apache Commons Collection. It is not really a bug in
> Commons Collection, but there is a lot of fuzz. So since we are doing
> somethign in the Apache Commons team against the problem we wanted to
> make a public statement.
>
> Here is a blog post, which was discussed on the developer mailinglist.
> What is needed to get it published via ASF blogs? (i.e. do you need a
> PMC vote or similiar?)
>
> The syntax for links is markdown, you might have to replace them (so
> the links are hidden). Let me know if you have some suggestions for
> improvement.
>
> Greetings
> Bernd (ecki@apache.org)
>
>
> ---
> 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: Blog post "commons" vulnerability

Posted by Gary Gregory <ga...@gmail.com>.

My name is spelled Gary Gregory BTW ;-)

Gary
On Nov 9, 2015 2:45 AM, "Bernd Eckenfels" <ec...@zusammenkunft.net> wrote:

> Hello Sally,
>
> currently there is a security vulnerability doing the rounds which uses
> as an example Apache Commons Collection. It is not really a bug in
> Commons Collection, but there is a lot of fuzz. So since we are doing
> somethign in the Apache Commons team against the problem we wanted to
> make a public statement.
>
> Here is a blog post, which was discussed on the developer mailinglist.
> What is needed to get it published via ASF blogs? (i.e. do you need a
> PMC vote or similiar?)
>
> The syntax for links is markdown, you might have to replace them (so
> the links are hidden). Let me know if you have some suggestions for
> improvement.
>
> Greetings
> Bernd (ecki@apache.org)
>
>
> ---
> 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
>
>