[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5645980D.9010105@gmail.com>
Date: Fri, 13 Nov 2015 08:58:05 +0100
From: Gsunde Orangen <gsunde.orangen@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-Request: Assign CVE for common-collections
remote code execution on deserialisation flaw
On 2015-11-12, 22:52 Mark Felder wrote:
>
>
> On Thu, Nov 12, 2015, at 03:04, Gsunde Orangen wrote:
>> CVE-Request:
>> I appreciate this general discussion around deserialization issues and
>> hope this will make a jump-start for sustainable improvements on both
>> Java and application level in the long run.
>> Aside of that however, I'd like to go back to Jason's original request
>> to Mitre to get a CVE ID assigned to this particular issue with the
>> Apache Commons Collections functors package (specifically in the
>> InvokerTransformer class).
>
> Is there any proof that Apache Commons Collections functors package
> isn't doing what it's intended to be doing? Everything I'm reading
> indicates that the problem is with applications believing they can
> *trust* the input, not that there's a bug in the functors package, ie,
> bad design.
I agree, and Florian stated similar concerns already in the beginning of
this thread [1]. However, what the functors package does seems to be
very easily to exploit through untrusted input. So the "bug" I would
assign to Commons-Collections is that it allows deserialization by
default while it shouldn't by default.
>
>> So people (esp. Java applications developers) have a unique reference
>> when analysing and fixing this particluar one (by e.g. removing the
>> class, make it non-serializable or wait for a new Commons Collections
>> release that includes that fix - whatever is most appropriate to their
>> application's context).
>>
>
> The currently proposed "fix"[1] is to disable functionality that is
> being used. This will break applications that need them.
>
> [1] https://issues.apache.org/jira/browse/COLLECTIONS-580
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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
