Thank you Sally! Gary On Nov 10, 2015 2:20 AM, "Sally Khudairi" <s...@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 annou...@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" <cfroh...@qualcomm.com> > To: Sally Khudairi <sallykhuda...@yahoo.com>; "e...@zusammenkunft.net" < > e...@zusammenkunft.net>; Gabriel Lawrence <gabriel.lawre...@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: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 <sallykhuda...@yahoo.com> > To: e...@zusammenkunft.net; "Frohoff, Chris" <cfroh...@qualcomm.com>; > Gabriel Lawrence <gabriel.lawre...@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: e...@zusammenkunft.net > To: "Frohoff, Chris" <cfroh...@qualcomm.com>, "Gabriel Lawrence" < > gabriel.lawre...@gmail.com>, "Commons Developers List" < > dev@commons.apache.org>, "Sally Khudairi" <sallykhuda...@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 > <sallykhuda...@yahoo.com.INVALID> To: "Frohoff, Chris" < > cfroh...@qualcomm.com>, 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" 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" <cfroh...@qualcomm.com> To: Gabriel Lawrence < > gabriel.lawre...@gmail.com>; Commons Developers List < > dev@commons.apache.org> Cc: Sally Khudairi <s...@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.lawre...@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.ste...@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" < > garydgreg...@gmail.com> > To: "Commons Developers List" < > dev@commons.apache.org> > Cc: <secur...@apache.org>, "Benedikt Ritter" < > brit...@apache.org>, "Sally Khudairi" <s...@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" <e...@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 ( > 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. > > > > > <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-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 > >
