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.sarg...@gmail.com> wrote: > 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@mail.langsec.org > https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss > >
_______________________________________________ langsec-discuss mailing list langsec-discuss@mail.langsec.org https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
