[langsec-discuss] Langsec and Java Object Serialization

Dan Kaminsky dan at doxpara.com
Fri Nov 13 22:58:09 UTC 2015


The problem is basically:

Security domains cross host boundaries (and some people think there are
intra-host boundaries too)
Performance domains cross host boundaries
Operating systems still act like we have single hosts
Reliability domains require that we can survive the loss of single hosts

All these impedance mismatches add up.

On Friday, November 13, 2015, Will Sargent <will.sargent at gmail.com> wrote:

> 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?
>
> Will.
>
>
>
>
>
>
> On Tue, Nov 10, 2015 at 7:49 AM, Sven Moritz Hallberg <pesco at khjk.org
> <javascript:_e(%7B%7D,'cvml','pesco at khjk.org');>> wrote:
>
>> Will Sargent <will.sargent at gmail.com
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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/73a4511a/attachment.html>


More information about the langsec-discuss mailing list