Re: CVE-Request: Assign CVE for common-collections remote code execution on deserialisation flaw

["Oracle Security Alerts (Thomas)" <secalert_us () oracle com>]

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