[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 11 Nov 2015 08:06:42 -0800
From: Tim <tim-security@...tinelchicken.org>
To: oss-security@...ts.openwall.com
Subject: Re: Assign CVE for common-collections remote code
execution on deserialisation flaw
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.
