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 . 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" is to disable functionality that is > being used. This will break applications that need them. > >  https://issues.apache.org/jira/browse/COLLECTIONS-580 I share Tim's view  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  http://seclists.org/oss-sec/2015/q4/238  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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ