[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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: <cross-project-issues-dev-bounces@xxxxxxxxxxx> on behalf of Carl Anderson <ccc@xxxxxxxxxx>
Antworten an: Cross issues <cross-project-issues-dev@xxxxxxxxxxx>
Datum: Dienstag, 17. November 2015 um 05:09
An: Cross issues <cross-project-issues-dev@xxxxxxxxxxx>
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 deserializingRob 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 <rstryker@xxxxxxxxxx>
To: cross-project-issues-dev@xxxxxxxxxxx
Date: 11/16/2015 05:17 PM
Subject: [cross-project-issues-dev] Question on commons-collections dependencies
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx





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@xxxxxxxxxxx
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
-------------------------------------------------------------