[langsec-discuss] Langsec and Java Object Serialization

matt matt at nycresistor.com
Tue Nov 10 03:28:22 UTC 2015

reminds me of buffer overflows in the SPI on the msp430. not 100% sure why
yet... might be that the datastream itself is vulnerable thus negating any
one off triage tactic.

On Mon, Nov 9, 2015 at 10:11 PM, Will Sargent <will.sargent at gmail.com>

> Hi all,
> I've been getting involved in the latest object serialization mess:
> https://tersesystems.com/2015/11/08/closing-the-open-door-of-java-object-serialization/
> So, the problem with Java object serialization is at first glance that
> people "deserialized untrusted objects."
> The problem here is unpacking that statement.
> What is trusted and untrusted?  Developers trust internal applications in
> the data center.  They trust JMX to run on an internal port inside the
> firewall.  "Trusted" is not a useful definition here, because developers
> trust things all the time on the principle that they "should" be secure,
> while security researchers are astonished that developers still have an
> idea of "inside" and "outside."
> How do you trust objects?  Well, they go through validation.  Or, if you
> like langsec (and who doesn't), they go through full recognition before
> processing.
> What's validation?  What's recognition?
> Well, it's when you figure out that a message is good.  When you can look
> at a serialized class and divine its goodness.
> And then I came across the following interesting blog posts by Sami Koivu:
> http://slightlyrandombrokenthoughts.blogspot.com/2010/07/why-complexpowerful-is-bad-combination.html
> http://slightlyrandombrokenthoughts.blogspot.com/2010/08/breaking-defensive-serialization.html
> The first paragraph is probably the best flavor:
> "I decided to write this bit after I started participating on the Cert/CC
> Java Secure Coding guidelines and was looking at the rules in the
> Serialization section. I immediately spotted some problems and started
> working on how to do serialization right, in terms of security. I already
> knew many of the pitfalls, but I quickly found that secure validation while
> deserializing is extremely difficult. Need proof? If Joshua Bloch can't
> get it right, and the (Oracle/Sun) Secure Coding Guidelines can't get it
> right, and key core classes can't get it right, what chances do the rest
> of us have?"
> 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.
> Any ideas?
> Will.
> _______________________________________________
> 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/20151109/b4992545/attachment.html>

More information about the langsec-discuss mailing list