[langsec-discuss] Langsec and Java Object Serialization
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
> > be faked or not (I wouldn't be surprised), but anything involving any
> > of internal query into the structure of a message seems inherently
> > doomed.
> I, too, read the Foxglove blog post you reference. 
> 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
> 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
> is objectively bad API design. An obvious alternative would be
> 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
> langsec-discuss mailing list
> langsec-discuss at mail.langsec.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the langsec-discuss