[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 12 Nov 2015 10:04:09 +0100
From: Gsunde Orangen <gsunde.orangen@...il.com>
To: oss-security@...ts.openwall.com
Cc: cve-assign@...re.org
Subject: CVE-Request: Assign CVE for common-collections remote code execution
on deserialisation flaw
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).
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).
On 2015-11-11, 17:06 Tim wrote
>
> Hi Moritz,
>
>> The problem here is that the amount of potential "sinks" is incredibly
>> large - everything on your classpath. No objection here to hardening the
>> specific instance, but thinking one will be safe afterwards is a
>> misconception. Like someone else put it, it's a game of whack-a-mole.
>
> Does every class in your classpath implement Serializable? If your
> library is implemented that way, it is broken. Web architectures used
> to be implemented such that you had to encode HTML in hundreds of
> separate places, one by one. Did we stop receiving and displaying
> user input because of it? No, we changed our archtectures to
> accommodate a better understanding of XSS.
>
> I don't think fixing one instance of a broken Serializable class will
> make us safe, but playing whack-a-mole with every application that
> uses serialization to transfer data isn't attractive either. Note
> that eliminating the use of serialization is harder because that
> requires a *functional* design change, rather than a change in
> implementation details.
>
>
>> Sure, as long as nobody does any funny stuff in their default
>> constructors, setters or getters. But the difference there is that these
>> unmarshallers (at least the ones I know of) only act on a very specific
>> set of classes you mostly control.
>> Looking at the flawed deserialization design at hand...
>
> I'm not saying Java's serialization architecture is good. Oracle
> definitely needs to do something. But passing the buck up to all
> applications and asking them to eliminate serialization is impractical
> and *dangerous*. The higher up you go in the software stack, the less
> developers understand security. Very few developers will get the
> message that they can't use it to process untrusted data and that will
> lead to a continued series of vulnerabilities.
>
>
>> And that's the assumption you are making. There is no such statement in
>> the Serializable definition, neither is anywhere defined what is
>> acceptable behavior for a readObject method and neither forbids the
>> collection API to do something dangerous in a getter (which in OpenJDK
>> seems to generally be an acceptable call).
>
> I agree that there's no statement about serialization security there.
> That's not surprising at all, because Oracle really sucks about
> security, always giving us a "not my problem" attitude. That's why I
> mentioned XMLDecoder. Even something as blatantly vulnerable as that
> interface doesn't receive any documentation that it shouldn't be used
> with untrusted data. So how can you expect them to rise to the
> occasion and document something slightly more nuanced?
>
> However, my assumption is the only one that makes sense, given the
> design of Java's serialization. Clearly, the lack of documentation
> has confused everyone, though, which is why we're having this
> discussion.
>
>
>> Maybe forcing them to take a position on the RMI implementation will be
>> of some use. They clearly assume deserialization is safe there and fun
>> fact, even use it for the authentication crendentials.
>
> Anything to nudge them into taking responsibility *for something,
> ever* would be a good start. However, last time I tried to convince
> them of something like this, they just told me "use a security
> manager". lulz. So good luck.
>
> Thanks much,
> tim
>
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.
