Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 13 Nov 2015 20:44:26 +0100
From: Gsunde Orangen <>
Subject: Re: CVE-Request: Assign CVE for common-collections
 remote code execution on deserialisation flaw


On 2015-11-13, 17:14 Lisa Bradley wrote:
> Seems Oracle has a CVE for this:
Thanks for the pointer!
CVE-2015-4852 was thus created by Oracle CNA (to address the issue in
WebLogic). I would propose to use this ID for Apache Commons-Collections
as well, plus as a reference for other applications that suffer from
unsafe deserialisation in combination with the functors packages.

But I am certainly not the one to decide ;-) - CC goes to Mitre, Apache
& Oracle.

Regarding Mark's (valid) concerns see further down below.


On 2015-11-13, 15:37 Mark Felder wrote:
> On Fri, Nov 13, 2015, at 01:58, Gsunde Orangen wrote:
>> I share Tim's view [2] and a dozen of (own) applications we checked
>> won't break. A property that re-enables deserialization of course would
>> help additionally: allow applications that really *need* this to get it
>> working; but that requires an explicit step - so latest by that time:
>> those, whose applications break after including a "fixed" version of
>> Commons-Collections would (hopefully) start to think about their design.
>> Gsunde
>> [1]
>> [2]
> This statement is how we have been operating our mitigation strategy:
> "Applications which use Apache Commons Collections and do not use
> deserialization are not vulnerable."
I agree

> Assuming that statement is correct, disabling deserialization by default
> doesn't offer additional protection to people. Instead it requires a
> code change when they upgrade to re-enable it and cause them to be
> vulnerable again.
It does offer additional protection to those applications who use
deserialization in general, but don't want to have this executed on the
unsafe Commons-Collections classes (or even are not aware that theses
classes are reachable via their remote interfaces).
>From my point of view and investigation this may be a lot of
applications in the world.
All those may not need to do anything else than upgrading their
Commons-Collections package to be safe from this particular issue.
(not addressing the important general issue of course yet...)

> Would the greater community be better served by additional documentation
> on how to safely handle the deserialization in their application?
Definitely yes, I agree! For the sustainable and long term.

> Is there such a method, or is this hopelessly broken?
I have to leave this up to the top Java experts (where I am not a member of)
Again, this is something very useful for the long term (and honestly I
would expect these activities starting latest by now - we may also await
the next posts, where others again will find other widespread classes
that are exploitable in a similar way. The race is on...)

My main point with having a single CVE ID and a new Apache
Commons-Collections version that fixes this ID is:
If you don't do it, then you end up with 1-5 CVE ids (individually for
those applications mentioned in the original publication: WebLogic,
Jenkins, etc.) and they all are reported in the context of these
individual applications only.
We would miss to address a significant number of applications in the
world, as it's not on their radar (but they have Commons-Collections
included, so that is on their radar)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.