Re: [cross-project-issues-dev] Question on commons-collectionsdependencies
Riena is NOT affected. Hessian does NOT call readObject but readResolve with a different semantic and no parameter. christian Von: mailto:cross-project-issues-dev-boun...@eclipse.org>> on behalf of Christian Campo mailto:christian.ca...@compeople.de>> Antworten an: Cross issues mailto:cross-project-issues-dev@eclipse.org>> Datum: Mittwoch, 18. November 2015 um 14:37 An: Cross issues mailto:cross-project-issues-dev@eclipse.org>> Betreff: Re: [cross-project-issues-dev] Question on commons-collectionsdependencies Commons.collections 3.2.2 is now also in Orbit so can be directly consumed by everyone who needs to… christian Von: mailto:cross-project-issues-dev-boun...@eclipse.org>> on behalf of Christian Campo mailto:christian.ca...@compeople.de>> Antworten an: Cross issues mailto:cross-project-issues-dev@eclipse.org>> Datum: Mittwoch, 18. November 2015 um 08:37 An: Cross issues mailto:cross-project-issues-dev@eclipse.org>> Betreff: Re: [cross-project-issues-dev] Question on commons-collectionsdependencies Commons.collections 3.2.2 is IP approved, so everyone interested can submit their Piggyback https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10385 christian Von: mailto:cross-project-issues-dev-boun...@eclipse.org>> on behalf of Christian Campo mailto:christian.ca...@compeople.de>> Antworten an: Cross issues mailto:cross-project-issues-dev@eclipse.org>> Datum: Dienstag, 17. November 2015 um 10:35 An: Cross issues mailto:cross-project-issues-dev@eclipse.org>> Betreff: Re: [cross-project-issues-dev] Question on commons-collectionsdependencies Hi Riena does not use Java Serialization and Deserialization for the remote service calls but it uses Hessian Serialization. While the protocol is totally different it also calls the readObject Method upon completion of the deserialization of the object which I believe could lead to a problem. I have opened a bug against Riena to track the effort https://bugs.eclipse.org/bugs/show_bug.cgi?id=482337 The solution for us is to use org.apache.commons.collections 3.2.2. Riena itself does not use commons.collections but org.apache.commons.beanutils which in turn uses commons.collections. What are about all the other projects that use remote services and I believe there are a few ? I wonder if they are also effected ? Christian P.s. Apache has released 3.2.2. Which fixes the problem https://commons.apache.org/proper/commons-collections/release_3_2_2.html (disables the problemactic class by default) Von: mailto:cross-project-issues-dev-boun...@eclipse.org>> on behalf of Carl Anderson mailto:c...@us.ibm.com>> Antworten an: Cross issues mailto:cross-project-issues-dev@eclipse.org>> Datum: Dienstag, 17. November 2015 um 05:09 An: Cross issues mailto:cross-project-issues-dev@eclipse.org>> Betreff: Re: [cross-project-issues-dev] Question on commons-collectionsdependencies Folks, First, org.apache.commons.collections is in Orbit, so there may be other teams affected by this possible exploit. We're working to get the "fixed" version - 3.2.2 - into Orbit. Second, WTP is in the process of determining how to handle this issue- you can follow https://bugs.eclipse.org/bugs/show_bug.cgi?id=482134 if you want to see how we decide to proceed. Part of the issue is that any adopter that extends Dali has the potential to deserialize persisted objects- we can't control what adopters do... but we can reduce/eliminate the possibility that a security hole can be exploited. FWIW, - Carl Anderson WTP Releng project lead [Inactive hide details for Rob Stryker ---11/16/2015 05:17:37 PM---Hi All: You may have seen the recent news about deserializing]Rob Stryker ---11/16/2015 05:17:37 PM---Hi All: You may have seen the recent news about deserializing random streams via From: Rob Stryker mailto:rstry...@redhat.com>> To: cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org> Date: 11/16/2015 05:17 PM Subject: [cross-project-issues-dev] Question on commons-collections dependencies Sent by: cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org> Hi All: You may have seen the recent news about deserializing random streams via commons-collections [1] and how this can lead to remote exploits. While it seems pretty unlikely that eclipse is vulnerable to this, it's worth noting that commons-collections is a requirement of org.eclipse.jpt.jpa, and possibly other bundles in various distributions. I may be misunderstanding the issue, but as I understand it, simply having the jar on the classpath isn't enough to exploit. Instead, you must actually be either 1) using the library to deserialize some persisted (untrusted) java object, or 2) be exposing ports and accepting arbitrary serialized data an
Re: [cross-project-issues-dev] Question on commons-collectionsdependencies
Commons.collections 3.2.2 is now also in Orbit so can be directly consumed by everyone who needs to... christian Von: mailto:cross-project-issues-dev-boun...@eclipse.org>> on behalf of Christian Campo mailto:christian.ca...@compeople.de>> Antworten an: Cross issues mailto:cross-project-issues-dev@eclipse.org>> Datum: Mittwoch, 18. November 2015 um 08:37 An: Cross issues mailto:cross-project-issues-dev@eclipse.org>> Betreff: Re: [cross-project-issues-dev] Question on commons-collectionsdependencies Commons.collections 3.2.2 is IP approved, so everyone interested can submit their Piggyback https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10385 christian Von: mailto:cross-project-issues-dev-boun...@eclipse.org>> on behalf of Christian Campo mailto:christian.ca...@compeople.de>> Antworten an: Cross issues mailto:cross-project-issues-dev@eclipse.org>> Datum: Dienstag, 17. November 2015 um 10:35 An: Cross issues mailto:cross-project-issues-dev@eclipse.org>> Betreff: Re: [cross-project-issues-dev] Question on commons-collectionsdependencies Hi Riena does not use Java Serialization and Deserialization for the remote service calls but it uses Hessian Serialization. While the protocol is totally different it also calls the readObject Method upon completion of the deserialization of the object which I believe could lead to a problem. I have opened a bug against Riena to track the effort https://bugs.eclipse.org/bugs/show_bug.cgi?id=482337 The solution for us is to use org.apache.commons.collections 3.2.2. Riena itself does not use commons.collections but org.apache.commons.beanutils which in turn uses commons.collections. What are about all the other projects that use remote services and I believe there are a few ? I wonder if they are also effected ? Christian P.s. Apache has released 3.2.2. Which fixes the problem https://commons.apache.org/proper/commons-collections/release_3_2_2.html (disables the problemactic class by default) Von: mailto:cross-project-issues-dev-boun...@eclipse.org>> on behalf of Carl Anderson mailto:c...@us.ibm.com>> Antworten an: Cross issues mailto:cross-project-issues-dev@eclipse.org>> Datum: Dienstag, 17. November 2015 um 05:09 An: Cross issues mailto:cross-project-issues-dev@eclipse.org>> Betreff: Re: [cross-project-issues-dev] Question on commons-collectionsdependencies Folks, First, org.apache.commons.collections is in Orbit, so there may be other teams affected by this possible exploit. We're working to get the "fixed" version - 3.2.2 - into Orbit. Second, WTP is in the process of determining how to handle this issue- you can follow https://bugs.eclipse.org/bugs/show_bug.cgi?id=482134 if you want to see how we decide to proceed. Part of the issue is that any adopter that extends Dali has the potential to deserialize persisted objects- we can't control what adopters do... but we can reduce/eliminate the possibility that a security hole can be exploited. FWIW, - Carl Anderson WTP Releng project lead [Inactive hide details for Rob Stryker ---11/16/2015 05:17:37 PM---Hi All: You may have seen the recent news about deserializing]Rob Stryker ---11/16/2015 05:17:37 PM---Hi All: You may have seen the recent news about deserializing random streams via From: Rob Stryker mailto:rstry...@redhat.com>> To: cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org> Date: 11/16/2015 05:17 PM Subject: [cross-project-issues-dev] Question on commons-collections dependencies Sent by: cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org> Hi All: You may have seen the recent news about deserializing random streams via commons-collections [1] and how this can lead to remote exploits. While it seems pretty unlikely that eclipse is vulnerable to this, it's worth noting that commons-collections is a requirement of org.eclipse.jpt.jpa, and possibly other bundles in various distributions. I may be misunderstanding the issue, but as I understand it, simply having the jar on the classpath isn't enough to exploit. Instead, you must actually be either 1) using the library to deserialize some persisted (untrusted) java object, or 2) be exposing ports and accepting arbitrary serialized data and then deserializing it. So the question is, do any eclipse distributions (classic, jee, etc) have any reason to open ports and accept remote connections and blindly deserialize the data? - Rob Stryker [1] http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org> To change your delivery
Re: [cross-project-issues-dev] Question on commons-collectionsdependencies
Commons.collections 3.2.2 is IP approved, so everyone interested can submit their Piggyback https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10385 christian Von: mailto:cross-project-issues-dev-boun...@eclipse.org>> on behalf of Christian Campo mailto:christian.ca...@compeople.de>> Antworten an: Cross issues mailto:cross-project-issues-dev@eclipse.org>> Datum: Dienstag, 17. November 2015 um 10:35 An: Cross issues mailto:cross-project-issues-dev@eclipse.org>> Betreff: Re: [cross-project-issues-dev] Question on commons-collectionsdependencies Hi Riena does not use Java Serialization and Deserialization for the remote service calls but it uses Hessian Serialization. While the protocol is totally different it also calls the readObject Method upon completion of the deserialization of the object which I believe could lead to a problem. I have opened a bug against Riena to track the effort https://bugs.eclipse.org/bugs/show_bug.cgi?id=482337 The solution for us is to use org.apache.commons.collections 3.2.2. Riena itself does not use commons.collections but org.apache.commons.beanutils which in turn uses commons.collections. What are about all the other projects that use remote services and I believe there are a few ? I wonder if they are also effected ? Christian P.s. Apache has released 3.2.2. Which fixes the problem https://commons.apache.org/proper/commons-collections/release_3_2_2.html (disables the problemactic class by default) Von: mailto:cross-project-issues-dev-boun...@eclipse.org>> on behalf of Carl Anderson mailto:c...@us.ibm.com>> Antworten an: Cross issues mailto:cross-project-issues-dev@eclipse.org>> Datum: Dienstag, 17. November 2015 um 05:09 An: Cross issues mailto:cross-project-issues-dev@eclipse.org>> Betreff: Re: [cross-project-issues-dev] Question on commons-collectionsdependencies Folks, First, org.apache.commons.collections is in Orbit, so there may be other teams affected by this possible exploit. We're working to get the "fixed" version - 3.2.2 - into Orbit. Second, WTP is in the process of determining how to handle this issue- you can follow https://bugs.eclipse.org/bugs/show_bug.cgi?id=482134 if you want to see how we decide to proceed. Part of the issue is that any adopter that extends Dali has the potential to deserialize persisted objects- we can't control what adopters do... but we can reduce/eliminate the possibility that a security hole can be exploited. FWIW, - Carl Anderson WTP Releng project lead [Inactive hide details for Rob Stryker ---11/16/2015 05:17:37 PM---Hi All: You may have seen the recent news about deserializing]Rob Stryker ---11/16/2015 05:17:37 PM---Hi All: You may have seen the recent news about deserializing random streams via From: Rob Stryker mailto:rstry...@redhat.com>> To: cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org> Date: 11/16/2015 05:17 PM Subject: [cross-project-issues-dev] Question on commons-collections dependencies Sent by: cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org> Hi All: You may have seen the recent news about deserializing random streams via commons-collections [1] and how this can lead to remote exploits. While it seems pretty unlikely that eclipse is vulnerable to this, it's worth noting that commons-collections is a requirement of org.eclipse.jpt.jpa, and possibly other bundles in various distributions. I may be misunderstanding the issue, but as I understand it, simply having the jar on the classpath isn't enough to exploit. Instead, you must actually be either 1) using the library to deserialize some persisted (untrusted) java object, or 2) be exposing ports and accepting arbitrary serialized data and then deserializing it. So the question is, do any eclipse distributions (classic, jee, etc) have any reason to open ports and accept remote connections and blindly deserialize the data? - Rob Stryker [1] http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org> To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev - compeople AG Untermainanlage 8 60329 Frankfurt/Main fon: +49 (0) 69 / 27 22 18 0 fax: +49 (0) 69 / 27 22 18 22 web: www.compeople.de Vorstand: Jürgen Wiesmaier Aufsichtsratsvorsitzender: Christian Glanz Sitz der Gesellschaft: Frankfurt/Main Handelsregister Frankfurt HRB 56759 USt-IdNr. DE207665352 --
Re: [cross-project-issues-dev] Question on commons-collectionsdependencies
Hi Riena does not use Java Serialization and Deserialization for the remote service calls but it uses Hessian Serialization. While the protocol is totally different it also calls the readObject Method upon completion of the deserialization of the object which I believe could lead to a problem. I have opened a bug against Riena to track the effort https://bugs.eclipse.org/bugs/show_bug.cgi?id=482337 The solution for us is to use org.apache.commons.collections 3.2.2. Riena itself does not use commons.collections but org.apache.commons.beanutils which in turn uses commons.collections. What are about all the other projects that use remote services and I believe there are a few ? I wonder if they are also effected ? Christian P.s. Apache has released 3.2.2. Which fixes the problem https://commons.apache.org/proper/commons-collections/release_3_2_2.html (disables the problemactic class by default) Von: mailto:cross-project-issues-dev-boun...@eclipse.org>> on behalf of Carl Anderson mailto:c...@us.ibm.com>> Antworten an: Cross issues mailto:cross-project-issues-dev@eclipse.org>> Datum: Dienstag, 17. November 2015 um 05:09 An: Cross issues mailto:cross-project-issues-dev@eclipse.org>> Betreff: Re: [cross-project-issues-dev] Question on commons-collectionsdependencies Folks, First, org.apache.commons.collections is in Orbit, so there may be other teams affected by this possible exploit. We're working to get the "fixed" version - 3.2.2 - into Orbit. Second, WTP is in the process of determining how to handle this issue- you can follow https://bugs.eclipse.org/bugs/show_bug.cgi?id=482134 if you want to see how we decide to proceed. Part of the issue is that any adopter that extends Dali has the potential to deserialize persisted objects- we can't control what adopters do... but we can reduce/eliminate the possibility that a security hole can be exploited. FWIW, - Carl Anderson WTP Releng project lead [Inactive hide details for Rob Stryker ---11/16/2015 05:17:37 PM---Hi All: You may have seen the recent news about deserializing]Rob Stryker ---11/16/2015 05:17:37 PM---Hi All: You may have seen the recent news about deserializing random streams via From: Rob Stryker mailto:rstry...@redhat.com>> To: cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org> Date: 11/16/2015 05:17 PM Subject: [cross-project-issues-dev] Question on commons-collections dependencies Sent by: cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org> Hi All: You may have seen the recent news about deserializing random streams via commons-collections [1] and how this can lead to remote exploits. While it seems pretty unlikely that eclipse is vulnerable to this, it's worth noting that commons-collections is a requirement of org.eclipse.jpt.jpa, and possibly other bundles in various distributions. I may be misunderstanding the issue, but as I understand it, simply having the jar on the classpath isn't enough to exploit. Instead, you must actually be either 1) using the library to deserialize some persisted (untrusted) java object, or 2) be exposing ports and accepting arbitrary serialized data and then deserializing it. So the question is, do any eclipse distributions (classic, jee, etc) have any reason to open ports and accept remote connections and blindly deserialize the data? - Rob Stryker [1] http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org> To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev - compeople AG Untermainanlage 8 60329 Frankfurt/Main fon: +49 (0) 69 / 27 22 18 0 fax: +49 (0) 69 / 27 22 18 22 web: www.compeople.de Vorstand: J?rgen Wiesmaier Aufsichtsratsvorsitzender: Christian Glanz Sitz der Gesellschaft: Frankfurt/Main Handelsregister Frankfurt HRB 56759 USt-IdNr. DE207665352 - ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Question on commons-collectionsdependencies
Folks, First, org.apache.commons.collections is in Orbit, so there may be other teams affected by this possible exploit. We're working to get the "fixed" version - 3.2.2 - into Orbit. Second, WTP is in the process of determining how to handle this issue- you can follow https://bugs.eclipse.org/bugs/show_bug.cgi?id=482134 if you want to see how we decide to proceed. Part of the issue is that any adopter that extends Dali has the potential to deserialize persisted objects- we can't control what adopters do... but we can reduce/eliminate the possibility that a security hole can be exploited. FWIW, - Carl Anderson WTP Releng project lead From: Rob Stryker To: cross-project-issues-dev@eclipse.org Date: 11/16/2015 05:17 PM Subject:[cross-project-issues-dev] Question on commons-collections dependencies Sent by:cross-project-issues-dev-boun...@eclipse.org Hi All: You may have seen the recent news about deserializing random streams via commons-collections [1] and how this can lead to remote exploits. While it seems pretty unlikely that eclipse is vulnerable to this, it's worth noting that commons-collections is a requirement of org.eclipse.jpt.jpa, and possibly other bundles in various distributions. I may be misunderstanding the issue, but as I understand it, simply having the jar on the classpath isn't enough to exploit. Instead, you must actually be either 1) using the library to deserialize some persisted (untrusted) java object, or 2) be exposing ports and accepting arbitrary serialized data and then deserializing it. So the question is, do any eclipse distributions (classic, jee, etc) have any reason to open ports and accept remote connections and blindly deserialize the data? - Rob Stryker [1] http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
