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

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

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