commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Blog post "commons" vulnerability
Date Tue, 10 Nov 2015 15:40:46 GMT
Thank you Sally!

Gary
On Nov 10, 2015 2:20 AM, "Sally Khudairi" <sk@apache.org> wrote:

> 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