[langsec-discuss] Langsec and Java Object Serialization

Will Sargent will.sargent at gmail.com
Tue Nov 10 04:57:19 UTC 2015


>
> 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

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/20151109/b475ad9c/attachment.html>


More information about the langsec-discuss mailing list