I liked your writeup! this seems to be a case of one party telling another party “hey take this program from me and run it in the same security domain that you do, thanks.” it’s “the same security domain” that’s the problem (along with the lack of realization that this is what ObjectInputStream does). it’s also a problem when the mechanism for enforcing the security domain, like the JVM or a javascript interpreter, is busted. if the security boundary is good though, then this isn’t a problem. when is the security boundary good though? maybe seL4 is good enough, maybe quark.
here’s a question though: if the management ports would take anything via ObjectInputStream, then what else could you do at the application layer? could you just read out and dump all the secret state of the system anyway, even if this OIS protocol wasn’t listening? I think the reason you don’t hear about this is because in the app clusters the security model is kind of inherently gooey on the inside because modeling the trust relationships between app servers is a ton of work for no upside and it’ll change all the time and probably degrade into an overly permissive state anyway… > On 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/ > > <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/07/why-complexpowerful-is-bad-combination.html> > > http://slightlyrandombrokenthoughts.blogspot.com/2010/08/breaking-defensive-serialization.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
