Re: Blog post "commons" vulnerability

[Gary Gregory]

My name is spelled Gary Gregory BTW ;-)

Gary
On Nov 9, 2015 2:45 AM, "Bernd Eckenfels"  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 (e...@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.
>
> 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=1713307=1713307_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 

Contributing (was: svn commit: r1713437 - /commons/proper/validator/trunk/src/test/java/org/apache/commons/validator/routines/ISSNValidatorTest.java)

[sebb AT ASF]

1) Please don't hijack threads - start a new thread with a new subject
as I have done here

2) Please don't cross-post to multiple lists

There is some info here:

http://commons.apache.org/volunteering.html

On 9 November 2015 at 14:44, Java Techie  wrote:
> Hi,
>
>
> Can anyone help me getting started! I urge to contribute in the Development
> Process!
>
>
>
> Regards,
> Gauravdeep Singh
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: invoker-defender Java agent

[Thomas Neidhart]

On 11/09/2015 12:34 PM, Eirik Bjørsnøs wrote:
> Hi,
> 
> Following the "recent" "news" about Java deserialization security issues, I
> decided to create:
> 
> https://github.com/kantega/invoker-defender/
> 
> This is a Java Agent which removes java.io.Serializable from classes known
> to be vulnerable to deserialization attacks. (Including InvokerTransformer)
> 
> I do not in any way consider this a complete solution to the problem since
> it only "fixes" a few well known classes.
> 
> But it might be something people could consider as a mitigation effort
> while vendors/projects work on more long-term fixes.
> 
> Feedback is welcome.

Thanks for sharing your work here.

Thomas

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Blog post "commons" vulnerability

[Sally Khudairi]

Thanks, Chris. I'll include your edits.
Status-wise, I'm uploading the copy to blogs.apache.org. I noticed that the 
"screenshot" referenced at https://twitter.com/gebl/status/662786601425080320 
is simply the tweet status. Is that intentional? Do  you want me to include a 
screenshot of this?
Please forward any additional comments/corrections/additions within the next 
hour if possible. I'd like to get this out before close of business Pacific 
Time if at all possible.
Thanking you in advance,Sally = = = = = vox +1 617 921 8656 off2 +1 646 583 
3362 skype sallykhudairi
  From: "Frohoff, Chris" 
 To: Gabriel Lawrence ; Commons Developers List 
 
Cc: Sally Khudairi  
 Sent: Monday, November 9, 2015 12:31 PM
 Subject: RE: Blog post "commons" vulnerability
   
#yiv5525942083 #yiv5525942083 -- _filtered #yiv5525942083 {panose-1:2 4 5 3 5 4 
6 3 2 4;} _filtered #yiv5525942083 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 
3 2 4;}#yiv5525942083 #yiv5525942083 p.yiv5525942083MsoNormal, #yiv5525942083 
li.yiv5525942083MsoNormal, #yiv5525942083 div.yiv5525942083MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv5525942083 a:link, 
#yiv5525942083 span.yiv5525942083MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv5525942083 a:visited, #yiv5525942083 
span.yiv5525942083MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv5525942083 
span.yiv5525942083hoenzb {}#yiv5525942083 span.yiv5525942083EmailStyle18 
{color:#1F497D;}#yiv5525942083 span.yiv5525942083EmailStyle19 
{color:windowtext;}#yiv5525942083 .yiv5525942083MsoChpDefault {} _filtered 
#yiv5525942083 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv5525942083 
div.yiv5525942083WordSection1 {}#yiv5525942083 Minor grammatical changes and 
comments inline. The main thing I’d suggest is expanding your patch to include 
any Serializable classes that perform reflection for completeness.    ---
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).

Building on Frohoff's tool ( add “ing”)
[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 show[s] that developers put too much trust in Java  ( 
remove plural)
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 overrides (*** replace 
“overwrites” with “overrides”)
[resolveClass()](http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html#resolveClass%28java.io.ObjectStreamClass%29)
to implement a whitelist approach ( link to 
http://www.ibm.com/developerworks/library/se-lookahead/?). This might, however, 
not always be
possible, such as when a framework or application server provides the endpoint. 
( add “such as”)
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 the Groovy runtime, Spring framework or Apache 

Re: [math] Smaller Packages / Artifacts / Dependencies

[Ole Ersoy]

On 11/07/2015 04:00 AM, Gilles wrote:

On Fri, 6 Nov 2015 15:06:35 -0600, Ole Ersoy wrote:

If math is broken up into smaller artifacts it will make it easier
for users to upgrade, even if it it breaks compatibility, as well as
speed up the release frequency.  So for example:
commons-math-optimization (Or even more granular
commons-math-optimization-lp, commons-math-optimization-ga,
commons-math-optimization-nlp, etc)
commons-math-simulation
commons-math-statistics
commons-math-ai (Neural Networks, ...)
etc.


I also believe that modularity is a worthy goal.

A first step would be to collect some statistics on inter-package
dependencies.


Personally I like modules and repositories that are very small and focused with 
as few dependencies as possible.  I'm probably in the extreme bulleye of the 
circle on this.  The reason I like it is because I can read a few usage lines 
in the github README.md and go.  It's easy to contribute to and minimizes 
indirection.  For example I think the optimizers are complex enough to warrant 
their own module.  The distributions probably belong in a single module, etc.

I'm still in the process of getting a demo repository setup, but it will be 
along these lines.  Once that's done it should make it really simple for 
someone to just clone, build, and get to work. It's nice if it's on Maven, but 
if the module is tiny, and easy to verify visually, then cloning and building 
is a reasonable way to get things done.


There will certainly be a "commons-math-core" containing packages
like "o.a.c.m.util" and "o.a.c.m.exception".
[At some point, releasing separate JARs could also provide us with
indirect feedback on which parts of CM are actually used.]

And the stars on github are a pretty good indicator as well.

Cheers,
- Ole


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: invoker-defender Java agent

[Eirik Bjørsnøs]

This might not be the best place to discuss this (?), but I do have a
follow-up on the agent-approuch to mitigating deserialization attacks:

I think it would be safer to whitelist expected uses of deserialization
instead of trying to blacklist the "bad" ones.

Of course, maintaining a list of safely deserialised classes by hand can be
quite a challenge. I think a possibly workable solution would be to record
actual uses of deserialisation on the running application. Then that list
could be used later as a whitelist.

Anything not whitelisted would then fail on deserialisation (not on
instanceof checks, but on actual readObject calls)

Here's a rough implementation of this "deserialization firewall" idea:

https://github.com/kantega/invoker-defender/tree/whitelist

The recording option could be useful in itself for anyone who wants to know
what and when their application is deserializing objects.

Cheers,
Eirik.

On Mon, Nov 9, 2015 at 12:34 PM, Eirik Bjørsnøs  wrote:

>
> Hi,
>
> Following the "recent" "news" about Java deserialization security issues,
> I decided to create:
>
> https://github.com/kantega/invoker-defender/
>
> This is a Java Agent which removes java.io.Serializable from classes known
> to be vulnerable to deserialization attacks. (Including InvokerTransformer)
>
> I do not in any way consider this a complete solution to the problem since
> it only "fixes" a few well known classes.
>
> But it might be something people could consider as a mitigation effort
> while vendors/projects work on more long-term fixes.
>
> Feedback is welcome.
>
> Cheers,
> Eirik.
>

Re: Blog post "commons" vulnerability

[Sally Khudairi]

Thanks, Bernd. Thanks, Gary.

I'm happy to publish for you when I'm back at the office later today.

To confirm, is there consensus on the content?

Thanks again,
Sally

[From the mobile; please excuse top-posting, spelling/spacing errors, and 
brevity]

- Reply message -
From: "Gary Gregory" 
To: "Commons Developers List" 
Cc: , "Benedikt Ritter" , "Sally 
Khudairi" 
Subject: Blog post "commons" vulnerability
Date: Mon, Nov 9, 2015 07:50

My name is spelled Gary Gregory BTW ;-)
Gary
On Nov 9, 2015 2:45 AM, "Bernd Eckenfels"  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 (e...@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.



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

Re: Blog post "commons" vulnerability

[Gabriel Lawrence]

On the whole this looks good to me... there are a few grammatical errors
though. Not being familiar with your process will there be a quick scrub at
the end to find all these or do you need me to point them out?

Also, chris is reviewing it as well and we should add him to this "We want
to thank Chris Frohoff and Gabriel Lawrence for reviewing this blog post."

thanks!

gabe

On Mon, Nov 9, 2015 at 8:42 AM, Phil Steitz  wrote:

> I think the post is nicely written and I don't personally object to
> anything in it.  I have not dug into the details of the subject
> though.  I wonder, also, if the "statement from Commons" bit is
> necessary.  We have never done this before and we are in general
> pretty conservative at the ASF level in making public statements qua
> ASF or qua Apache Foo.  Why wouldn't a post syndicated via
> PlanetApache as Gary or Bernd do?
>
> Phil
>
> On 11/9/15 9:06 AM, Sally Khudairi wrote:
> > Thanks, Bernd. Thanks, Gary.
> >
> > I'm happy to publish for you when I'm back at the office later today.
> >
> > To confirm, is there consensus on the content?
> >
> > Thanks again,
> > Sally
> >
> > [From the mobile; please excuse top-posting, spelling/spacing errors,
> and brevity]
> >
> > - Reply message -
> > From: "Gary Gregory" 
> > To: "Commons Developers List" 
> > Cc: , "Benedikt Ritter" ,
> "Sally Khudairi" 
> > Subject: Blog post "commons" vulnerability
> > Date: Mon, Nov 9, 2015 07:50
> >
> > My name is spelled Gary Gregory BTW ;-)
> > Gary
> > On Nov 9, 2015 2:45 AM, "Bernd Eckenfels" 
> 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 (e...@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 

Re: [math] Version mgt idea

[Ole Ersoy]

If I'm interested in some functionality that is 'beta' then I first have to 
realize that it's 'beta'...Maybe just tag the branch beta. After that there's 
probably (Judging from the number of people communicating here) 1/2 people 
interested.  Isn't it easier for them to just just check out the beta branch 
and manage the process internally using their own internal 'beta' naming 
convention until they are happy with the quality?

From here it looks like the core problem is that there are two many modules 
intermingled in CM causing friction / weighing down the release process for 
each of the individual modules (Which I'm currently imagining).

Cheers,
- Ole

On 11/06/2015 06:51 PM, Gary Gregory wrote:

On Fri, Nov 6, 2015 at 4:02 PM, Phil Steitz  wrote:


On 11/6/15 4:46 PM, Gary Gregory wrote:

On Fri, Nov 6, 2015 at 3:01 PM, Phil Steitz 

wrote:

On 11/6/15 2:51 PM, Gary Gregory wrote:

On Fri, 6 Nov 2015 09:17:18 -0700, Phil Steitz wrote:

Here is an idea that might break our deadlock re backward
compatibility, versioning and RERO:

Agree that odd numbered versions have stable APIs - basically
adhere
to Commons rules - no breaks within 3.0, 3.1, ..., 3.x... or 5.0,
5.1... but even-numbered lines can include breaks -


...

This sounds awfully complicated for my puny human brain.

How, exactly?  Seems pretty simple to me.  The even-numbered release
lines may have compat breaks; but the odd-numbered do not.

It's bad enough that I have to remember how each FOSS project treats
versions numbers, but having an exception within a Commons component is
even worse. This is a non-starter for me.

Do you have any better suggestions?  The problem we are trying to
solve is we can't RERO while sticking to the normal compat rules
without turning major versions all the time, which forces users to
repackage all the time and us to support more versions concurrently
than we have bandwidth to do.


I do not see how a different version scheme will determine how many
branches the community supports.

If we just keep one 4.x branch that keeps cutting (possibly
incompatible) releases, that is just one line, one branch.  If we
have to cut 4.1, 4.2, 4.3 as 4, 5, 6 instead and we don't allow any
compat breaks, we end up having to maintain and release 4.0.1,
5.0.1, 6.0.1 instead of just 4.3.1, for example, or we just strand
the 4, 5 users in terms of bug fixes as we move on to 6.

Breaking BC without a package and coord change is a no-go.

We have done this before and we will probably do it again - and more
if we have to don't separate out an unstable line.

  You have to
think about this jar as a dependency that can be deeply nested in a
software stack. Commons components are such creatures. I unfortunately

run

into this more than I'd like: Big FOSS project A depends on B which

depends

on C. Then I want to integrate with Project X which depends on Y which
depends on different versions of B and C. Welcome to jar hell if B and C
are not compatible. If B and C follow the rule of break-BC -> new
package/coords, then all is well.

The mitigation here is that we would not expect the even-numbered
releases to be deployed widely.


Respectfully Phil, my point is that while this might be true, it is in
practice irrelevant. We cannot control the spread of our jars and their
usage, hence the importance of BC.

Gary


Phil

Gary



Phil

Gary



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org







-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Blog post "commons" vulnerability

[Phil Steitz]

I think the post is nicely written and I don't personally object to
anything in it.  I have not dug into the details of the subject
though.  I wonder, also, if the "statement from Commons" bit is
necessary.  We have never done this before and we are in general
pretty conservative at the ASF level in making public statements qua
ASF or qua Apache Foo.  Why wouldn't a post syndicated via
PlanetApache as Gary or Bernd do?

Phil

On 11/9/15 9:06 AM, Sally Khudairi wrote:
> Thanks, Bernd. Thanks, Gary.
>
> I'm happy to publish for you when I'm back at the office later today.
>
> To confirm, is there consensus on the content?
>
> Thanks again,
> Sally
>
> [From the mobile; please excuse top-posting, spelling/spacing errors, and 
> brevity]
>
> - Reply message -
> From: "Gary Gregory" 
> To: "Commons Developers List" 
> Cc: , "Benedikt Ritter" , "Sally 
> Khudairi" 
> Subject: Blog post "commons" vulnerability
> Date: Mon, Nov 9, 2015 07:50
>
> My name is spelled Gary Gregory BTW ;-)
> Gary
> On Nov 9, 2015 2:45 AM, "Bernd Eckenfels"  
> 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 (e...@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 

Re: Blog post "commons" vulnerability

[Benedikt Ritter]

Hi,

I think it is appropriate to sign the post with  "Bernd Eckenfels and Gary
Gregory, on behalf of the Apache Commons PMC"
The content has been open for discussion long enough for anybody to raise
concerns. Several PMC members have been involved in this issue.

Thank you for helping, Sally!
Benedikt

2015-11-10 0:52 GMT+01:00 Sally Khudairi :

> Thanks, Chris.
>
> I read that as an internal comment to the PMC/folks on the list.
>
> I have incorporated all other comments/corrections/additions.
>
> Please let me know if I have misinterpreted this.
>
> Kind regards,
> Sally
>
>
> [From the mobile; please excuse top-posting, spelling/spacing errors, and
> brevity]
>
> - Reply message -
> From: "Frohoff, Chris" 
> To: "Sally Khudairi" , "e...@zusammenkunft.net" <
> e...@zusammenkunft.net>, "Gabriel Lawrence" ,
> "Commons Developers List" 
> Subject: Blog post "commons" vulnerability
> Date: Mon, Nov 9, 2015 18:42
>
> All,
>
> I just wanted to make sure that this didn’t get missed in the comments:
>
> “I’d suggest doing this for anything Serializable that performs reflection
> for completeness.”
>
> I think there’s a reasonable chance another gadget chain could be
> constructed from one or more of the below classes. I’d suggest extending
> your patch similarly
> to these if it’s not too difficult.
>
> $ grep -ER -e "lang.reflect.(Method|Constructor)" src/main
> --include=*.java -l | grep -v InvokerTransformer | xargs -n1 grep -l
> Serializable
>
> src/main/java/org/apache/commons/collections4/functors/InstantiateFactory.java
>
> src/main/java/org/apache/commons/collections4/functors/InstantiateTransformer.java
>
> src/main/java/org/apache/commons/collections4/functors/PrototypeFactory.java
>
> Thanks,
>
> -Chris
>
>
>
> From: Sally Khudairi [mailto:sallykhuda...@yahoo.com]
>
>
> Sent: Monday, November 09, 2015 3:15 PM
>
> To: Sally Khudairi; e...@zusammenkunft.net; Frohoff, Chris; Gabriel
> Lawrence; Commons Developers List
>
> Subject: Re: Blog post "commons" vulnerability
>
>
>
>
>
>
>
> Just to clarify re: PMC affiliation, may I suggest it appear as:
>
>
>
>
>
>
>
> > Authors: Bernd Eckenfels and Gary Gregory, members of the Apache Commons
> Project Management Committee
>
>
>
>
>
>
>
>
>
>
>
> I'm happy to proceed tonight if this meets your approval. If you can
> please give the go-ahead by 7PM ET (= ~45 minutes from now), that
> would be great.
>
>
>
>
>
>
>
> Otherwise, I'm happy to issue tomorrow morning.
>
>
>
>
>
>
>
> Thanks,
>
> Sally
>
>
>
>
>
>
>
>
>
>
>
> = = = = = vox +1 617 921 8656 off2 +1 646 583 3362 skype sallykhudairi
>
>
>
>
>
>
>
>
>
>
>
> From: Sally Khudairi 
>
> To: e...@zusammenkunft.net; "Frohoff, Chris" ;
> Gabriel Lawrence ;
> Commons Developers List 
>
>
> Sent: Monday, November 9, 2015 5:29 PM
>
> Subject: Re: Blog post "commons" vulnerability
>
>
>
>
>
>
>
> Thanks so much, Bernd.
>
>
>
>
>
>
>
> Personally, I prefer mentioning PMC affiliation, as it adds credibility,
> but I'll post it however you'd like.
>
>
>
>
>
>
>
> OK re: tweet screenshot; I've included it.
>
>
>
>
>
>
>
> Please let me know when you're ready, and I'll publish.
>
>
>
>
>
>
>
> Warmly,
>
>
>
> Sally
>
>
>
>
>
>
>
>
>
>
>
> [From the mobile; please excuse top-posting, spelling/spacing errors, and
> brevity]
>
>
>
>
> - Reply message -
>
> From: e...@zusammenkunft.net
>
> To: "Frohoff, Chris" , "Gabriel Lawrence" <
> gabriel.lawre...@gmail.com>, "Commons Developers List" <
> dev@commons.apache.org>,
> "Sally Khudairi" 
>
> Subject: Blog post "commons" vulnerability
>
> Date: Mon, Nov 9, 2015 17:24
>
>
>
>
>
>
>
>
>
> Hello Sally,
>
> Yes it is just a screenshot of a tweet, I could not come up with a useful
> graohic for the topic and since discussion on Twitter somewhat powered all
> the fuzz I figured it would fit.
>
> Regarding Phils comment I think having some "apache commons" communication
> on blogs does help the bonding with the project, however since the topic is
> urgend I suggest two minor edits
>
> Authors: Bernd Eckenfels and Gary Gregory (Apache Commons Committers)
> Title: Widespread Java Object de-serialisation vulnerabilities
>
> (I.e. less formal. Gary I guess you would agree not to mention PMC?)
>
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
>
> -Original Message-
> From: Sally Khudairi 
> To: "Frohoff, Chris" , Gabriel Lawrence <
> gabriel.lawre...@gmail.com>, Commons Developers List <
> dev@commons.apache.org>
> Sent: Mo., 09 Nov. 2015 22:36
> Subject: Re: Blog post "commons" vulnerability
>
> Thanks, Chris. I'll include your edits.
> Status-wise, I'm uploading the copy to blogs.apache.org. I noticed that
> the "screenshot" 

Re: Blog post "commons" vulnerability

[Sally Khudairi]

Thanks so much, Bernd.

Personally, I prefer mentioning PMC affiliation, as it adds credibility, but 
I'll post it however you'd like.

OK re: tweet screenshot; I've included it.

Please let me know when you're ready, and I'll publish.

Warmly,
Sally


[From the mobile; please excuse top-posting, spelling/spacing errors, and 
brevity]

- Reply message -
From: e...@zusammenkunft.net
To: "Frohoff, Chris" , "Gabriel Lawrence" 
, "Commons Developers List" 
, "Sally Khudairi" 
Subject: Blog post "commons" vulnerability
Date: Mon, Nov 9, 2015 17:24

Hello Sally,

Yes it is just a screenshot of a tweet, I could not come up with a useful 
graohic for the topic and since discussion on Twitter somewhat powered all the 
fuzz I figured it would fit.

Regarding Phils comment I think having some "apache commons" communication on 
blogs does help the bonding with the project, however since the topic is urgend 
I suggest two minor edits

Authors: Bernd Eckenfels and Gary Gregory (Apache Commons Committers)
Title: Widespread Java Object de-serialisation vulnerabilities

(I.e. less formal. Gary I guess you would agree not to mention PMC?)

Gruss
Bernd


-- 
http://bernd.eckenfels.net

-Original Message-
From: Sally Khudairi 
To: "Frohoff, Chris" , Gabriel Lawrence 
, Commons Developers List 
Sent: Mo., 09 Nov. 2015 22:36
Subject: Re: Blog post "commons" vulnerability

Thanks, Chris. I'll include your edits.
Status-wise, I'm uploading the copy to blogs.apache.org. I noticed that the 
"screenshot" referenced at https://twitter.com/gebl/status/662786601425080320 
is simply the tweet status. Is that intentional? Do  you want me to include a 
screenshot of this?
Please forward any additional comments/corrections/additions within the next 
hour if possible. I'd like to get this out before close of business Pacific 
Time if at all possible.
Thanking you in advance,Sally = = = = = vox +1 617 921 8656 off2 +1 646 583 
3362 skype sallykhudairi
From: "Frohoff, Chris" 
To: Gabriel Lawrence ; Commons Developers List 
 
Cc: Sally Khudairi  
Sent: Monday, November 9, 2015 12:31 PM
Subject: RE: Blog post "commons" vulnerability

#yiv5525942083 #yiv5525942083 -- _filtered #yiv5525942083 {panose-1:2 4 5 3 5 4 
6 3 2 4;} _filtered #yiv5525942083 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 
3 2 4;}#yiv5525942083 #yiv5525942083 p.yiv5525942083MsoNormal, #yiv5525942083 
li.yiv5525942083MsoNormal, #yiv5525942083 div.yiv5525942083MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv5525942083 a:link, 
#yiv5525942083 span.yiv5525942083MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv5525942083 a:visited, #yiv5525942083 
span.yiv5525942083MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv5525942083 
span.yiv5525942083hoenzb {}#yiv5525942083 span.yiv5525942083EmailStyle18 
{color:#1F497D;}#yiv5525942083 span.yiv5525942083EmailStyle19 
{color:windowtext;}#yiv5525942083 .yiv5525942083MsoChpDefault {} _filtered 
#yiv5525942083 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv5525942083 
div.yiv5525942083WordSection1 {}#yiv5525942083 Minor grammatical changes and 
comments inline. The main thing I’d suggest is expanding your patch to include 
any Serializable classes that perform reflection for completeness.---
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).

Building on Frohoff's tool ( add “ing”)
[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 show[s] that developers put too much trust in Java  ( 
remove plural)
Object Serialization. Some even de-serialize objects
pre-authentication. When deserializing an Object in Java you typically
cast it 

[VOTE] Release Commons Collections 3.2.2 Based on RC1

[Thomas Neidhart]

Hi all,

in order to provide a work-around for the known remote code exploit via
java de-serialization of malicious InvokerTransformer instances, I would
like to start a vote to release Commons Collections 3.2.2 based on RC1.

I would kindly ask people to review the RC especially wrt the following
topics:

 * OSGI compatibility
 * reproducing the exploits and verifying that it provides protection
 * any kind of regression that this release might create with existing
applications

Notes:

 * the site will not be published, it just serves as a reference to
access the various reports. After a successful vote, the current 4.X
branch site will be updated with relevant information and published.

 * some tests might fail with various IBM JDK 6 JREs, these are known
issues and have been worked-around in the 4.X branch but are not
back-ported to this release.


Collections 3.2.2 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/collections/
(svn revision 11092)

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1115/commons-collections/commons-collections/3.2.2/

Details of changes since 3.2.1 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/collections/RELEASE-NOTES.txt

http://people.apache.org/builds/commons/collections/3.2.2/RC1/changes-report.html

The tag is here:

https://svn.apache.org/repos/asf/commons/proper/collections/tags/COLLECTIONS_3_2_2_RC1
(svn revision 1713561)

Site:
http://people.apache.org/builds/commons/collections/3.2.2/RC1/

Clirr Report (compared to 3.2.1):

http://people.apache.org/builds/commons/collections/3.2.2/RC1/clirr-report.html

RAT Report:

http://people.apache.org/builds/commons/collections/3.2.2/RC1/rat-report.html

KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.

This vote will close no sooner that 72 hours from now, i.e. after 2300
GMT 12-November 2015

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thanks,

Thomas

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Blog post "commons" vulnerability

[ecki]

Hello Sally,

Yes it is just a screenshot of a tweet, I could not come up with a useful 
graohic for the topic and since discussion on Twitter somewhat powered all the 
fuzz I figured it would fit.

Regarding Phils comment I think having some "apache commons" communication on 
blogs does help the bonding with the project, however since the topic is urgend 
I suggest two minor edits

Authors: Bernd Eckenfels and Gary Gregory (Apache Commons Committers)
Title: Widespread Java Object de-serialisation vulnerabilities

(I.e. less formal. Gary I guess you would agree not to mention PMC?)

Gruss
Bernd


-- 
http://bernd.eckenfels.net

-Original Message-
From: Sally Khudairi 
To: "Frohoff, Chris" , Gabriel Lawrence 
, Commons Developers List 
Sent: Mo., 09 Nov. 2015 22:36
Subject: Re: Blog post "commons" vulnerability

Thanks, Chris. I'll include your edits.
Status-wise, I'm uploading the copy to blogs.apache.org. I noticed that the 
"screenshot" referenced at https://twitter.com/gebl/status/662786601425080320 
is simply the tweet status. Is that intentional? Do  you want me to include a 
screenshot of this?
Please forward any additional comments/corrections/additions within the next 
hour if possible. I'd like to get this out before close of business Pacific 
Time if at all possible.
Thanking you in advance,Sally = = = = = vox +1 617 921 8656 off2 +1 646 583 
3362 skype sallykhudairi
  From: "Frohoff, Chris" 
 To: Gabriel Lawrence ; Commons Developers List 
 
Cc: Sally Khudairi  
 Sent: Monday, November 9, 2015 12:31 PM
 Subject: RE: Blog post "commons" vulnerability
   
#yiv5525942083 #yiv5525942083 -- _filtered #yiv5525942083 {panose-1:2 4 5 3 5 4 
6 3 2 4;} _filtered #yiv5525942083 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 
3 2 4;}#yiv5525942083 #yiv5525942083 p.yiv5525942083MsoNormal, #yiv5525942083 
li.yiv5525942083MsoNormal, #yiv5525942083 div.yiv5525942083MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv5525942083 a:link, 
#yiv5525942083 span.yiv5525942083MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv5525942083 a:visited, #yiv5525942083 
span.yiv5525942083MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv5525942083 
span.yiv5525942083hoenzb {}#yiv5525942083 span.yiv5525942083EmailStyle18 
{color:#1F497D;}#yiv5525942083 span.yiv5525942083EmailStyle19 
{color:windowtext;}#yiv5525942083 .yiv5525942083MsoChpDefault {} _filtered 
#yiv5525942083 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv5525942083 
div.yiv5525942083WordSection1 {}#yiv5525942083 Minor grammatical changes and 
comments inline. The main thing I’d suggest is expanding your patch to include 
any Serializable classes that perform reflection for completeness.---
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).

Building on Frohoff's tool ( add “ing”)
[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 show[s] that developers put too much trust in Java  ( 
remove plural)
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, 

Re: [COLLECTIONS] Bad press on twitter following serialization issue

[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 (s...@apache.org
).

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](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.
>
> 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=1713307=1713307_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
> 

Re: [COLLECTIONS] Bad press on twitter following serialization issue

[Bernd Eckenfels]

Am Mon, 9 Nov 2015 09:36:41 +0100
schrieb 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

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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [collections] Review of proposed fix for InvokerTransformer exploit

[Thomas Neidhart]

On Mon, Nov 9, 2015 at 10:37 AM, Emmanuel Bourg  wrote:

> Le 08/11/2015 23:21, Thomas Neidhart a écrit :
>
> > please review the proposed fix for this issue here:
>
> The exception message ends with a comma, is this a typo? I suggest
> mentioning the system property in the message, such that someone
> hitting the exception immediately knows how to work around it.
>

yes, I wanted to add this information, but forgot to finish.
I also need to add a paragraph to the class javadoc outlining the change.


>
> Also:
>
> !"true".equalsIgnoreCase(deserializeProperty)
>
> is shorter than:
>
> deserializeProperty == null ||
> !deserializeProperty.equalsIgnoreCase("true")
>

yes indeed, will change too.

Thanks,

Thomas

Re: [COLLECTIONS] Bad press on twitter following serialization issue

[Bernd Eckenfels]

Thanks Timo!

Am Mon, 9 Nov 2015 10:18:18 +0100
schrieb Timo :

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

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=1713307=1713307_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. 

Blog post "commons" vulnerability

[Bernd Eckenfels]

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 (e...@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.

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=1713307=1713307_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 

Re: Blog post "commons" vulnerability

[Sally Khudairi]

Thanks, Chris.

I read that as an internal comment to the PMC/folks on the list.

I have incorporated all other comments/corrections/additions.

Please let me know if I have misinterpreted this.

Kind regards,
Sally


[From the mobile; please excuse top-posting, spelling/spacing errors, and 
brevity]

- Reply message -
From: "Frohoff, Chris" 
To: "Sally Khudairi" , "e...@zusammenkunft.net" 
, "Gabriel Lawrence" , 
"Commons Developers List" 
Subject: Blog post "commons" vulnerability
Date: Mon, Nov 9, 2015 18:42

All,

I just wanted to make sure that this didn’t get missed in the comments:

“I’d suggest doing this for anything Serializable that performs reflection for 
completeness.”

I think there’s a reasonable chance another gadget chain could be constructed 
from one or more of the below classes. I’d suggest extending your patch 
similarly
to these if it’s not too difficult.

$ grep -ER -e "lang.reflect.(Method|Constructor)" src/main --include=*.java -l 
| grep -v InvokerTransformer | xargs -n1 grep -l Serializable
src/main/java/org/apache/commons/collections4/functors/InstantiateFactory.java
src/main/java/org/apache/commons/collections4/functors/InstantiateTransformer.java
src/main/java/org/apache/commons/collections4/functors/PrototypeFactory.java

Thanks,

-Chris



From: Sally Khudairi [mailto:sallykhuda...@yahoo.com]


Sent: Monday, November 09, 2015 3:15 PM

To: Sally Khudairi; e...@zusammenkunft.net; Frohoff, Chris; Gabriel Lawrence; 
Commons Developers List

Subject: Re: Blog post "commons" vulnerability







Just to clarify re: PMC affiliation, may I suggest it appear as:







> Authors: Bernd Eckenfels and Gary Gregory, members of the Apache Commons 
> Project Management Committee











I'm happy to proceed tonight if this meets your approval. If you can please 
give the go-ahead by 7PM ET (= ~45 minutes from now), that
would be great.







Otherwise, I'm happy to issue tomorrow morning.







Thanks,

Sally











= = = = = vox +1 617 921 8656 off2 +1 646 583 3362 skype sallykhudairi











From: Sally Khudairi 

To: e...@zusammenkunft.net; "Frohoff, Chris" ; Gabriel 
Lawrence ;
Commons Developers List 


Sent: Monday, November 9, 2015 5:29 PM

Subject: Re: Blog post "commons" vulnerability







Thanks so much, Bernd.







Personally, I prefer mentioning PMC affiliation, as it adds credibility, but 
I'll post it however you'd like.







OK re: tweet screenshot; I've included it.







Please let me know when you're ready, and I'll publish.







Warmly,



Sally











[From the mobile; please excuse top-posting, spelling/spacing errors, and 
brevity]




- Reply message -

From: e...@zusammenkunft.net

To: "Frohoff, Chris" , "Gabriel Lawrence" 
, "Commons Developers List" 
,
"Sally Khudairi" 

Subject: Blog post "commons" vulnerability

Date: Mon, Nov 9, 2015 17:24









Hello Sally,

Yes it is just a screenshot of a tweet, I could not come up with a useful 
graohic for the topic and since discussion on Twitter somewhat powered all the 
fuzz I figured it would fit.

Regarding Phils comment I think having some "apache commons" communication on 
blogs does help the bonding with the project, however since the topic is urgend 
I suggest two minor edits

Authors: Bernd Eckenfels and Gary Gregory (Apache Commons Committers)
Title: Widespread Java Object de-serialisation vulnerabilities

(I.e. less formal. Gary I guess you would agree not to mention PMC?)

Gruss
Bernd


-- 
http://bernd.eckenfels.net

-Original Message-
From: Sally Khudairi 
To: "Frohoff, Chris" , Gabriel Lawrence 
, Commons Developers List 
Sent: Mo., 09 Nov. 2015 22:36
Subject: Re: Blog post "commons" vulnerability

Thanks, Chris. I'll include your edits.
Status-wise, I'm uploading the copy to blogs.apache.org. I noticed that the 
"screenshot" referenced at https://twitter.com/gebl/status/662786601425080320 
is simply the tweet status. Is that intentional? Do  you want me to include a 
screenshot of this?
Please forward any additional comments/corrections/additions within the next 
hour if possible. I'd like to get this out before close of business Pacific 
Time if at all possible.
Thanking you in advance,Sally = = = = = vox +1 617 921 8656 off2 +1 646 583 
3362 skype sallykhudairi
From: "Frohoff, Chris" 
To: Gabriel Lawrence ; Commons Developers List 
 
Cc: Sally Khudairi  
Sent: Monday, November 9, 2015 12:31 PM
Subject: RE: Blog post "commons" 

Re: Blog post "commons" vulnerability

[Chris Frohoff]

Not sure if this was coming through from my work email, so I'm resending from 
here...

All,


 
I just wanted to make sure that this didn’t get missed in thecomments:


 
“I’d suggest doing this foranything Serializable that performs reflection for 
completeness.”


 
I think there’s a reasonable chance another gadget chain couldbe constructed 
from one or more of the below classes. I’d suggest extendingyour patch 
similarly to these if it’s not too difficult.


 
$ grep -ER -e "lang.reflect.(Method|Constructor)"src/main --include=*.java -l | 
grep -v InvokerTransformer | xargs -n1 grep -lSerializable

src/main/java/org/apache/commons/collections4/functors/InstantiateFactory.java

src/main/java/org/apache/commons/collections4/functors/InstantiateTransformer.java

src/main/java/org/apache/commons/collections4/functors/PrototypeFactory.java


 
Thanks,


 
-Chris

 


 On Monday, November 9, 2015 2:29 PM, Sally Khudairi 
 wrote:
   

 Thanks so much, Bernd.

Personally, I prefer mentioning PMC affiliation, as it adds credibility, but 
I'll post it however you'd like.

OK re: tweet screenshot; I've included it.

Please let me know when you're ready, and I'll publish.

Warmly,
Sally


[From the mobile; please excuse top-posting, spelling/spacing errors, and 
brevity]

- Reply message -
From: e...@zusammenkunft.net
To: "Frohoff, Chris" , "Gabriel Lawrence" 
, "Commons Developers List" 
, "Sally Khudairi" 
Subject: Blog post "commons" vulnerability
Date: Mon, Nov 9, 2015 17:24

Hello Sally,

Yes it is just a screenshot of a tweet, I could not come up with a useful 
graohic for the topic and since discussion on Twitter somewhat powered all the 
fuzz I figured it would fit.

Regarding Phils comment I think having some "apache commons" communication on 
blogs does help the bonding with the project, however since the topic is urgend 
I suggest two minor edits

Authors: Bernd Eckenfels and Gary Gregory (Apache Commons Committers)
Title: Widespread Java Object de-serialisation vulnerabilities

(I.e. less formal. Gary I guess you would agree not to mention PMC?)

Gruss
Bernd


-- 
http://bernd.eckenfels.net

-Original Message-
From: Sally Khudairi 
To: "Frohoff, Chris" , Gabriel Lawrence 
, Commons Developers List 
Sent: Mo., 09 Nov. 2015 22:36
Subject: Re: Blog post "commons" vulnerability

Thanks, Chris. I'll include your edits.
Status-wise, I'm uploading the copy to blogs.apache.org. I noticed that the 
"screenshot" referenced at https://twitter.com/gebl/status/662786601425080320 
is simply the tweet status. Is that intentional? Do  you want me to include a 
screenshot of this?
Please forward any additional comments/corrections/additions within the next 
hour if possible. I'd like to get this out before close of business Pacific 
Time if at all possible.
Thanking you in advance,Sally = = = = = vox +1 617 921 8656 off2 +1 646 583 
3362 skype sallykhudairi
From: "Frohoff, Chris" 
To: Gabriel Lawrence ; Commons Developers List 
 
Cc: Sally Khudairi  
Sent: Monday, November 9, 2015 12:31 PM
Subject: RE: Blog post "commons" vulnerability

#yiv5525942083 #yiv5525942083 -- _filtered #yiv5525942083 {panose-1:2 4 5 3 5 4 
6 3 2 4;} _filtered #yiv5525942083 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 
3 2 4;}#yiv5525942083 #yiv5525942083 p.yiv5525942083MsoNormal, #yiv5525942083 
li.yiv5525942083MsoNormal, #yiv5525942083 div.yiv5525942083MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv5525942083 a:link, 
#yiv5525942083 span.yiv5525942083MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv5525942083 a:visited, #yiv5525942083 
span.yiv5525942083MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv5525942083 
span.yiv5525942083hoenzb {}#yiv5525942083 span.yiv5525942083EmailStyle18 
{color:#1F497D;}#yiv5525942083 span.yiv5525942083EmailStyle19 
{color:windowtext;}#yiv5525942083 .yiv5525942083MsoChpDefault {} _filtered 
#yiv5525942083 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv5525942083 
div.yiv5525942083WordSection1 {}#yiv5525942083 Minor grammatical changes and 
comments inline. The main thing I’d suggest is expanding your patch to include 
any Serializable classes that perform reflection for completeness.    ---
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 

Re: Blog post "commons" vulnerability

[Sally Khudairi]

Just to clarify re: PMC affiliation, may I suggest it appear as:
> Authors: Bernd Eckenfels and Gary Gregory, members of the Apache Commons 
> Project Management Committee
 
I'm happy to proceed tonight if this meets your approval. If you can please 
give the go-ahead by 7PM ET (= ~45 minutes from now), that would be great.
Otherwise, I'm happy to issue tomorrow morning.
Thanks,
Sally

= = = = = vox +1 617 921 8656 off2 +1 646 583 3362 skype sallykhudairi
  From: Sally Khudairi 
 To: e...@zusammenkunft.net; "Frohoff, Chris" ; Gabriel 
Lawrence ; Commons Developers List 
 
 Sent: Monday, November 9, 2015 5:29 PM
 Subject: Re: Blog post "commons" vulnerability
   
Thanks so much, Bernd.
Personally, I prefer mentioning PMC affiliation, as it adds credibility, but 
I'll post it however you'd like.
OK re: tweet screenshot; I've included it.
Please let me know when you're ready, and I'll publish.
Warmly,Sally

[From the mobile; please excuse top-posting, spelling/spacing errors, and 
brevity]
- Reply message -
From: e...@zusammenkunft.net
To: "Frohoff, Chris" , "Gabriel Lawrence" 
, "Commons Developers List" 
, "Sally Khudairi" 
Subject: Blog post "commons" vulnerability
Date: Mon, Nov 9, 2015 17:24
Hello Sally,

Yes it is just a screenshot of a tweet, I could not come up with a useful 
graohic for the topic and since discussion on Twitter somewhat powered all the 
fuzz I figured it would fit.

Regarding Phils comment I think having some "apache commons" communication on 
blogs does help the bonding with the project, however since the topic is urgend 
I suggest two minor edits

Authors: Bernd Eckenfels and Gary Gregory (Apache Commons Committers)
Title: Widespread Java Object de-serialisation vulnerabilities

(I.e. less formal. Gary I guess you would agree not to mention PMC?)

Gruss
Bernd


-- 
http://bernd.eckenfels.net

-Original Message-
From: Sally Khudairi 
To: "Frohoff, Chris" , Gabriel Lawrence 
, Commons Developers List 
Sent: Mo., 09 Nov. 2015 22:36
Subject: Re: Blog post "commons" vulnerability

Thanks, Chris. I'll include your edits.
Status-wise, I'm uploading the copy to blogs.apache.org. I noticed that the 
"screenshot" referenced at https://twitter.com/gebl/status/662786601425080320 
is simply the tweet status. Is that intentional? Do  you want me to include a 
screenshot of this?
Please forward any additional comments/corrections/additions within the next 
hour if possible. I'd like to get this out before close of business Pacific 
Time if at all possible.
Thanking you in advance,Sally = = = = = vox +1 617 921 8656 off2 +1 646 583 
3362 skype sallykhudairi
  From: "Frohoff, Chris" 
 To: Gabriel Lawrence ; Commons Developers List 
 
Cc: Sally Khudairi  
 Sent: Monday, November 9, 2015 12:31 PM
 Subject: RE: Blog post "commons" vulnerability
   
#yiv5525942083 #yiv5525942083 -- _filtered #yiv5525942083 {panose-1:2 4 5 3 5 4 
6 3 2 4;} _filtered #yiv5525942083 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 
3 2 4;}#yiv5525942083 #yiv5525942083 p.yiv5525942083MsoNormal, #yiv5525942083 
li.yiv5525942083MsoNormal, #yiv5525942083 div.yiv5525942083MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv5525942083 a:link, 
#yiv5525942083 span.yiv5525942083MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv5525942083 a:visited, #yiv5525942083 
span.yiv5525942083MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv5525942083 
span.yiv5525942083hoenzb {}#yiv5525942083 span.yiv5525942083EmailStyle18 
{color:#1F497D;}#yiv5525942083 span.yiv5525942083EmailStyle19 
{color:windowtext;}#yiv5525942083 .yiv5525942083MsoChpDefault {} _filtered 
#yiv5525942083 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv5525942083 
div.yiv5525942083WordSection1 {}#yiv5525942083 Minor grammatical changes and 
comments inline. The main thing I’d suggest is expanding your patch to include 
any Serializable classes that perform reflection for completeness.---
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 

Re: [collections] Review of proposed fix for InvokerTransformer exploit

[Emmanuel Bourg]

Le 08/11/2015 23:21, Thomas Neidhart a écrit :

> please review the proposed fix for this issue here:

The exception message ends with a comma, is this a typo? I suggest
mentioning the system property in the message, such that someone
hitting the exception immediately knows how to work around it.

Also:

!"true".equalsIgnoreCase(deserializeProperty)

is shorter than:

deserializeProperty == null || !deserializeProperty.equalsIgnoreCase("true")


Emmanuel Bourg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [COLLECTIONS] Bad press on twitter following serialization issue

[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](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.

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=1713307=1713307_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 

Re: [COLLECTIONS] Bad press on twitter following serialization issue

[Timo]

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

invoker-defender Java agent

[Eirik Bjørsnøs]

Hi,

Following the "recent" "news" about Java deserialization security issues, I
decided to create:

https://github.com/kantega/invoker-defender/

This is a Java Agent which removes java.io.Serializable from classes known
to be vulnerable to deserialization attacks. (Including InvokerTransformer)

I do not in any way consider this a complete solution to the problem since
it only "fixes" a few well known classes.

But it might be something people could consider as a mitigation effort
while vendors/projects work on more long-term fixes.

Feedback is welcome.

Cheers,
Eirik.