Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 17 Nov 2015 16:17:03 -0800
From: "Oracle Security Alerts (Thomas)" <>
To: Gsunde Orangen <>,,
Subject: Re: CVE-Request: Assign CVE for common-collections
 remote code execution on deserialisation flaw

Hash: SHA1

We do not have a problem with this use of the CVE# we registered

Thomas Keefe
Oracle Security Alerts

On 11/13/2015 11:44 AM, Gsunde Orangen wrote:
> inline...
> 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-Collectio
> 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, Apach
> & Oracle.
> Regarding Mark's (valid) concerns see further down below.
> Gsunde
> 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 wo
>>> help additionally: allow applications that really *need* this to get
>>> 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 des
>>> 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 defa
>> 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 th
> 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 documentat
>> 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 memb
er 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 awa
> 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)

Version: GnuPG v2


Powered by blists - more mailing lists

Your e-mail address:

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

Powered by Openwall GNU/*/Linux - Powered by OpenVZ