commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sally Khudairi ...@apache.org>
Subject Re: Blog post "commons" vulnerability
Date Tue, 10 Nov 2015 10:20:29 GMT
Hello everyone --we are live:
 - ASF "Foundation" blog http://s.apache.org/bsA - @TheASF Twitter feed https://twitter.com/TheASF/status/664023691051843584
...plus sent to announce@apache.org and our dedicated media/analyst distribution list. This
will appear on the apache.org homepage during the next auto-update, which should take place
within the hour.
Thanks so much for your help with this. I'm glad we were able to get it out!
Warmly,Sally
+ copying press@ to keep the team in the loop. = = = = = vox +1 617 921 8656 off2 +1 646
583 3362 skype sallykhudairi
      From: "Frohoff, Chris" <cfrohoff@qualcomm.com>
 To: Sally Khudairi <sallykhudairi@yahoo.com>; "ecki@zusammenkunft.net" <ecki@zusammenkunft.net>;
Gabriel Lawrence <gabriel.lawrence@gmail.com>; Commons Developers List <dev@commons.apache.org>

 Sent: Monday, November 9, 2015 6:42 PM
 Subject: RE: Blog post "commons" vulnerability
   
#yiv5799872531 #yiv5799872531 -- _filtered #yiv5799872531 {font-family:Helvetica;panose-1:2
11 6 4 2 2 2 2 2 4;} _filtered #yiv5799872531 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv5799872531
{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv5799872531 {font-family:Consolas;panose-1:2
11 6 9 2 2 4 3 2 4;}#yiv5799872531 #yiv5799872531 p.yiv5799872531MsoNormal, #yiv5799872531
li.yiv5799872531MsoNormal, #yiv5799872531 div.yiv5799872531MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv5799872531
a:link, #yiv5799872531 span.yiv5799872531MsoHyperlink {color:blue;text-decoration:underline;}#yiv5799872531
a:visited, #yiv5799872531 span.yiv5799872531MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv5799872531
pre {margin:0in;margin-bottom:.0001pt;font-size:10.0pt;}#yiv5799872531 span.yiv5799872531HTMLPreformattedChar
{font-family:Consolas;}#yiv5799872531 span.yiv5799872531EmailStyle19 {color:#1F497D;}#yiv5799872531
.yiv5799872531MsoChpDefault {font-size:10.0pt;} _filtered #yiv5799872531 {margin:1.0in 1.0in
1.0in 1.0in;}#yiv5799872531 div.yiv5799872531WordSection1 {}#yiv5799872531 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:sallykhudairi@yahoo.com]
Sent: Monday, November 09, 2015 3:15 PM
To: Sally Khudairi; ecki@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 <sallykhudairi@yahoo.com>
To: ecki@zusammenkunft.net; "Frohoff, Chris" <cfrohoff@qualcomm.com>; Gabriel Lawrence
<gabriel.lawrence@gmail.com>; Commons Developers List <dev@commons.apache.org>
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: ecki@zusammenkunft.net
To: "Frohoff, Chris" <cfrohoff@qualcomm.com>, "Gabriel Lawrence" <gabriel.lawrence@gmail.com>,
"Commons Developers List" <dev@commons.apache.org>, "Sally Khudairi" <sallykhudairi@yahoo.com>
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 <sallykhudairi@yahoo.com.INVALID>
To: "Frohoff, Chris" <cfrohoff@qualcomm.com>, Gabriel Lawrence <gabriel.lawrence@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" 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" <cfrohoff@qualcomm.com>
 To: Gabriel Lawrence <gabriel.lawrence@gmail.com>; Commons Developers List <dev@commons.apache.org>
 Cc: Sally Khudairi <sk@haloworldwide.com>   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 (**** add “the”, replace “Sprint” with “Spring) 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(**** I’d suggest doing this for anything Serializable that
performs reflection for completeness). 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 (**** added comma) unknown useable
gadget. So replacing your installations with a hardened (**** replaced “unknow” with “unknown”)
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).
           From: Gabriel Lawrence [mailto:gabriel.lawrence@gmail.com] Sent: Monday, November
09, 2015 9:05 AM To: Commons Developers List Cc: Sally Khudairi; Frohoff, Chris Subject: Re:
Blog post "commons" vulnerability    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 <phil.steitz@gmail.com> 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" <garydgregory@gmail.com>
> To: "Commons Developers List" <dev@commons.apache.org> > Cc: <security@apache.org>,
"Benedikt Ritter" <britter@apache.org>, "Sally Khudairi" <sk@apache.org> >
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"
<ecki@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       ---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail:
dev-help@commons.apache.org            

  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message