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)" <secalert_us@...cle.com>
To: Gsunde Orangen <gsunde.orangen@...il.com>, oss-security@...ts.openwall.com,
        security@...che.org
CC: cve-assign@...re.org
Subject: Re: CVE-Request: Assign CVE for common-collections
 remote code execution on deserialisation flaw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We do not have a problem with this use of the CVE# we registered
(CVE-2015-4852).

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:
>> https://blogs.oracle.com/security/entry/security_alert_cve_2015_4852
> 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
ns
> 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
e
> & 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
uld
>>> 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 des
ign.
>>>
>>> Gsunde
>>>
>>> [1] http://seclists.org/oss-sec/2015/q4/238
>>> [2] http://seclists.org/oss-sec/2015/q4/263
>>
>> 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
ult
>> 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
e
> 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
ion
>> 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
it
> 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)
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlZLw30ACgkQf36Vx1dNy5r+xgCfS37T2qb+nqQDNjfQIGd8l484
zC8An0rJgwO+bkDYKGqckw/Uqo13VZUs
=Bm+E
-----END PGP SIGNATURE-----

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