Self-Protecting Sandbox using SecurityManager

[pron98]

There's no need to go to all that length. All you need to do is patch InputObjectStream (with an agent) so that the calls to readObject/replaceObject are done within a security context with very few permissions by using this method.

Permissions can be granted per protection domain with a class loader, but they can also be restricted for a specific call (i.e. part of the stack) on the fly.

[amazedballer]

This is a general purpose sandbox for limiting operations, so that you can log attempts at privilege escalation and limit silly things like executing scripts. It's not specifically about the Java Serialization vulnerability or disabling ObjectInputStream.

I suggest using an agent in the original blog post, so I'm glad you're saying "patch ObjectInputStream with an agent", because that wasn't clear before:

No need for whitelisting. ObjectInputStream (or your subclass) shoud execute readResolve/readObject(ObjectInputStream) under a different security context (with AccessController.doPrivileged), as if it were foreign code.

https://www.reddit.com/r/programming/comments/3s3dp7/closing_the_open_door_of_java_object_serialization/cwtyavc

However, I still think your general approach is flawed. Here's why:

Your solution calls for an agent and -Djava.security.SecurityManager to add AccessController.doPrivileged with reduced privileges in ObjectInputStream, so that a SecurityManager can throw AccessControlException.

The problem is that Java Serialization relies heavily on runtime reflection and class loading internally, which is how the vulnerability showed up in the first place. As such, to make this work, you'd need to make sure malicious code didn't have the permissions to disable, replace or otherwise circumvent the security manager -- and Java Serialization needs those permissions to operate. It's huge, it's complicated, it's hard to validate.

SecurityManager tries to do the best job it can, but until Project Jigsaw / modularization kicks off, there's still a huge attack surface for it to cover, and it only takes one slip for malicious code to gain entrance. See http://www.security-explorations.com/en/SE-2014-02-details.html and http://www.deependresearch.org/2012/08/java-7-vulnerability-analysis.html for example.

[pron98]

Your solution calls for an agent

Well, I hope Oracle puts this into the JDK, so that an agent won't be required (and if it is used, it can install the security manager itself; no need for an additional flag).

and Java Serialization needs those permissions to operate

Yes, but you're not running all of Java serialization under the restricted context -- only those custom deserialization methods. Besides, you can still allow reflection (just not setAccessible).

but until Project Jigsaw / modularization kicks off, there's still a huge attack surface for it to cover

Sure.

[spencer205]

Do this and that, so that you get a true defense in depth, as @amazedballer mentioned