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

[Gsunde Orangen <gsunde.orangen () gmail com>]

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

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