[langsec-discuss] Langsec and Java Object Serialization

Will Sargent will.sargent at gmail.com
Fri Nov 13 18:40:59 UTC 2015

Well, we can turn it off.   Same with XMLEncoder.

At this point, I'm more worried about RMI / JMX replacements -- that's not
going away, and there's not going to be an easy answer.

More generally, I think the "compromised host" attack needs to be played
up, as developers just clearly DON'T GET that a data center will be
penetrated.  At this point, it's about damage limitation and bulkheading.
Assume failure, assume compromise.

So I know there are three concepts here.  Validation, verification and
trust.  Maybe recognition is a fourth one.

Trust -- Trust is blind.  You trust your JVM and your initial configuration
that you loaded.  Maybe an HSM / TPM.  Everything else, no.  Not even
things that have been produced through validation.

Validation -- does the thingy satisfy specific requirements?

Verification -- for a given thingy, do the things produced from the thingy
meet the conditions imposed on the thingy?

Recognition -- can you produce a thingy from this?

Does this sound about right?  Where do people get their definitions from?


On Tue, Nov 10, 2015 at 7:49 AM, Sven Moritz Hallberg <pesco at khjk.org>

> Will Sargent <will.sargent at gmail.com> writes:
> > Basically, the only way I know of to securely check the goodness of java
> > serialization is to check the class name.  I have no real idea if that
> can
> > be faked or not (I wouldn't be surprised), but anything involving any
> kind
> > of internal query into the structure of a message seems inherently
> > doomed.
> I, too, read the Foxglove blog post you reference. [1]
> I find it relatively troubling/telling that the term "parsing" isn't
> used anywhere and that the message seems to be "don't deserialize
> untrusted data".
> Deserialization is parsing. In the author's own words:
> > Most programming languages provide built-in ways for users to output
> > application data to disk or stream it over the network. The process of
> > converting application data to another format (usually binary) suitable
> > for transportation is called serialization. The process of reading data
> > back in after it has been serialized is called unserialization.
> Clearly, given some input, parsing is exactly what one should be doing
> with it, "untrusted" or not. The issue is that Java deserialization maps
> onto the set of objects that are of *any* serializable class.
> The example code then goes:
>     MyObject objectFromDisk = (MyObject)ois.readObject();
> As evidenced by the cast, the intended input language is the set of
> serializations of objects of class MyObject. Unfortunately, this is
> validated only after parsing. As you note, this is a spectacular
> counter-example to the Langsec war cry of "full recognition before
> processing".
> What the above should really read is:
>     MyObject objectFromDisk = ois.readObject(MyObject);
> I'm not sure if that's valid Java, but the point is that the parser
> should be restricted to the expected class.
> Obviously, whitelisting is still much better than nothing.
> I find two things interesting in this issue:
> 1. It props up a suspicion I've long held of data formats that purport
>    to be "self-describing": If you know what you are parsing you don't
>    need the data to describe itself. If on the other hand you don't know
>    what you're parsing and invent some way for the data (i.e. the
>    adversary) to tell you, you are doing nothing else than building a
>    language backdoor.
> 2. It shows us that
>        (MyObject)ois.readObject()
>    is objectively bad API design. An obvious alternative would be
>        MyObject.readObject(is)
>    but I suspect many a Java designer would wave it off as naive and
>    impractical for one reason or another. My intuition in contrast is
>    that a "naive" formulation not being practical often indicates flaws
>    elsewhere.
> -SMH
> _______________________________________________
> langsec-discuss mailing list
> langsec-discuss at mail.langsec.org
> https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.langsec.org/pipermail/langsec-discuss/attachments/20151113/255ad253/attachment.html>

More information about the langsec-discuss mailing list