I think that two important actions are missing: - Cut new releases. - Create a CVE id. (No idea, who can do that or how its done.)
We should wait with any publication until these are completed. Jochen On Tue, Nov 10, 2015 at 8:19 AM, Benedikt Ritter <benerit...@gmail.com> wrote: > 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 <sallykhuda...@yahoo.com.invalid>: > >> 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" <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> >> 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 <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 >> -- The next time you hear: "Don't reinvent the wheel!" http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
