[langsec-discuss] Langsec and Java Object Serialization

Andrew Ruef munin at mimisbrunnr.net
Tue Nov 10 05:11:09 UTC 2015


Well objects are just a poor mans closures so another view of serialization is that you’re just sending the first order parameters, and you forget that you could send higher order parameters too ;) if you don’t do that, then you’re “fine”. 

I think the rest of this discussion is described by Raymond Chens “Airtight Hatchway”: http://blogs.msdn.com/b/oldnewthing/archive/2006/05/08/592350.aspx <http://blogs.msdn.com/b/oldnewthing/archive/2006/05/08/592350.aspx> except in this case it’s a multi system boundary. The designers of the system don’t anticipate that nodes could start sending bad queries. 

Have you looked at the Fabric project? They seem to take this philosophy to heart when designing distributed systems… 

> On Nov 9, 2015, at 11:57 PM, Will Sargent <will.sargent at gmail.com> wrote:
> 
> 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 
> 
> The problem is that most people think that object serialization is for sending data.  It isn't -- it's sending computation.  (And if you're sending computation, you should just send Scala pickling and be done with it, but that's another conversation.)
>  
> 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 
> 
> Right -- this is part of the "application security" problem space that I don't quite understand yet.  All the terms I know for an "inside the data center" attack are from the actual pen testers themselves -- they talk about "lateral movement" / "pivoting" / "beachheads".  It's about a directed attack.
> 
> As far as I know, there is no developer term for a compromised partner -- I'm not sure there's even a concept of it.  If there is, and I'm missing it, please tell me.  I am not a security professional -- I am just a programmer too dumb not to poke at the bitey things.
> 
> So whatever "appsec" means, I don't know.  I imagine that in the same way "reactive" is about dealing and living with failure as a fact of applications, "appsec" is about dealing and living with compromise as a fact of applications.  Maybe we should call it "compsec."
> 
> So "what else could you do at the application layer" means having to think about how a partner microservice could tell you to execute horrible queries.  It means having to think about how a partner could try to stab you in the back.  
> 
> More practically, if you accept Object serialization, you can get a "billion laughs" attack sent pretty easily: https://gist.github.com/coekie/a27cc406fc9f3dc7a70d <https://gist.github.com/coekie/a27cc406fc9f3dc7a70d>
> 
> So there really isn't a good answer for object serialization.  It should be shot in the head and replaced with JSON or CBOR. It's too big and complex to be safe.
> 
> But this still doesn't answer the larger question -- how do you know you can trust your partner microservices?  Even if they're just sending application level command consisting of immutable data packets made out of safe primitives, those commands could still be off. The command itself could be completely valid, and the partner microservice compromised and the combination or sequence of commands off (i.e. querying the entire database or repeating user validation attempts 1000s of times).
> 
> So, I can apply some of the same principles as reactive -- if you get enough errors or timeouts or enough lag from a node, you can flag it, so you should be able to do the same thing to get enough data to set a "compromise" flag.  But to know that a node is compromised just from its output, you have to either see something that's a total red flag, or you have to keep track of the odd traffic coming from it.  That... is tough to codify.
> 
> Will.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.langsec.org/pipermail/langsec-discuss/attachments/20151110/0cd650d0/attachment.html>


More information about the langsec-discuss mailing list