[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5641360D.8070102@eenterphace.org>
Date: Tue, 10 Nov 2015 01:10:53 +0100
From: Moritz Bechler <mbechler@...terphace.org>
To: oss-security@...ts.openwall.com
Subject: Re: Assign CVE for common-collections remote code
execution on deserialisation flaw
Am 09.11.2015 um 22:53 schrieb Tim:
>
>> This is not a vulnerability in the library. How can this feature allow
>> remote code execution if it does not involve any networking at all?
>>
>> The root cause is the incorrect use of Java deserialization. As long as
>> you do not fix that, something else on the classpath will serve the role
>> of Apache Commons Collections.
>
> Can you elaborate on this last point? Can you better describe the
> root cause, as you see it, and what should have been done differently
> by the systems using Apache Commons?
The main problem is that deserialization can easily get you into
executing code paths (either through custom serialization code or other
funny code). Given that the regular deserialization routines allow any
(Serializable) class to be deserialized, you would have to make sure
that cannot happen by any interaction of any code (what, given the sheer
amount of library code in typical java projects, you simply cannot). If
you cannot, you either must refrain from deserializing any untrusted or
privilege-boundary-crossing data or use a whitelisting approach to
reduce the amount of classes you need to check for problems (that of
course still leaves room for error and often is not easily possible as
the code performing the deserialization is buried in libraries or even
the standard library).
Regarding the issue at hand, it's pretty clear that the involved parties
make different assumptions about whether it should be okay to
deserialize untrusted data and there simply is no way of differentiating
between the two - one Serializable to rule them all. (Standard library
behaviour, OpenJDK, is also a bit frightening, as they, for example,
assume it is okay to call into collection api methods).
Given that, the only sane advice I have right now is - don't do it at
all. No RMI, JMX, whatever. Of course that is pretty inconvenient.
This needs to be fixed on a much lower level than commons collections.
Whitelisting might be a mitigation, but right now, e.g. for RMI code you
cannot really do it without patching your JRE.
Moritz
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.
