[langsec-discuss] Langsec and Java Object Serialization

Will Sargent will.sargent at gmail.com
Sat Jan 9 18:37:49 UTC 2016

> I liked these posts! The sandbox stuff in Java is ridiculous. It seems like there’s a parallel 
> between the usability of the sandbox API and the usability of crypto APIs: there are primitives  
> that exist to try and provide some kind of security guarantee but they’re so difficult  
> to use that they are rarely used correctly.

Well… the sandbox model in Java is covering a huge amount of surface area.  One of the methods is called “checkPackageAccess” and does nothing but call through to make sure you’re not accessing sun internal classes.

Oracle has clearly realized the mistake, and added compact profiles in 1.8:


and is planning to cut down even further with modules in Project Jigsaw:


But of course there is a huge wail from all the systems that rely on sun.misc.Unsafe and run time reflection etc, because it means more work on their end, for what they see as little gain.

> Traditionally the “Turducken Security Model” is called “defense in depth” and is considered  
> a “best practice” ;)

It’s tongue in cheek, but I think that “defense in depth” only means something when you know that each layer covers something different, and it doesn’t get at the DJB model of “small programs paranoid about their input.”  Even if the system isn’t compromised on the root layer, if an attacker can wade through the appsec and deploy object serialization to compromise every node in your cluster, then they still have total control over your computation.

> It seems that this kind of sandbox and containment is overall a good idea because projects  
> adapt them to their benefit: vsftpd, chrome, quark, etc, and others ignore them to their  
> determent: firefox. It follows in a tradition that goes back to operating system design:  
> the boundary between user mode and kernel mode. Traditionally this boundary becomes  
> porous due to low level defects in the system call layer that allows for code execution,  
> but absent those defects the design provides the protection that you want.
> Probably? “Sandbox” in this case just seems to be “a way to evaluate something with a reduced  
> set of credentials” and “trust in the access control mechanism”. For example, Haskell  
> LIO: http://www.scs.stanford.edu/~dm/home/papers/stefan:lio.pdf  
> https://hackage.haskell.org/package/lio  
> which you can just use in your code to enforce security policies. So when you go to unmarshal  
> some data or something, the function that does the evaluation drops to a low security  
> label and then if crazy stuff happens during unmarshaling it can’t touch anything else.  

That was the initial idea, but it’s not quite working out like that.

I am looking more at some work done by the Arno Mittelbach, Java Sandbox guy:

* http://blog.datenwerke.net/p/java-sandbox-03-documentation.html?m=1https://forum.reportserver.net/viewtopic.php?pid=825http://sourceforge.net/projects/dw-sandbox/https://github.com/csm/java-sandbox/

Great work, looks like he wasn’t marketing it very well...

> Of course, back to the original point: these kinds of compromises happen because someone  
> looks at ObjectInputStream and thinks “that looks fine” and there’s nothing in Java  
> at the type level that tells you “this is dangerous” so out comes the foot gun…

Right, and AccessController.doPrivileged is a stack escape system.  As soon as it’s called, it only looks at the immediate caller, which is typically something else in the java.io package — so running in a sandbox is no protection at all when the flaw is in the runtime itself.

Likewise, you can’t run things in an AccessController({ … }, null, noPerms) block because you can always call doPrivileged and give those permissions back to you as long as you’re in the same ProtectionDomain...


More information about the langsec-discuss mailing list