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

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

It seems that IBM Websphere [1] is now using the same CVE ID as Oracle
WebLogic [2]: CVE-2015-4852
So I would go with that ID with any application around the
Commons-Collections issues.

Gsunde

[1] http://www.ibm.com/support/docview.wss?uid=swg21970575
[2] https://blogs.oracle.com/security/entry/security_alert_cve_2015_4852


On 2015-11-13, 23:07 Gsunde Orangen wrote:
> On 2015-11-13, 22:07 Mark Felder wrote:
> > On Fri, Nov 13, 2015, at 08: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."
> >
> >
> > CERT has released a statement[1] indicating that you are vulnerable
> > simply by having this in your classpath. It does not matter if you are
> > doing deserialization or not. The patch[2] to disable serialization
> > functionality by default seems to me like the only option to mitigate
> > the CVE now.
> >
> >
> > [1] https://www.kb.cert.org/vuls/id/576313
> > [2]
> > https://issues.apache.org/jira/secure/attachment/12771520/COLLECTIONS-580.patch
> ... and Apache.org's statement [3] summarizes the issue and the current
> status quite well
>
> [3]
> https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread