java - deserialization of untrusted data workaround

Question

Last year we encountered the so-called java object deserialization vulnerability (not a java's problem as it looks), which is deserializing an object which might lead to Remote Code Execution (RCE) or Denial of Service (DoS) attacks.

Refer, https://dzone.com/articles/java-serialization-vulnerability-threatens-million for details.

Basically, if the code fails to validate the incoming object, it's vulnerable.

Impact of this attack would be pretty high as described in, What is the security impact of deserializing untrusted data in Java?

First the attacker used classes from InvokerTransformer from Apache Commons Collections as a way to build the attack chain.

Solution 1 : Blacklisting The classes which have been used to build the gadget chain are not accepted.

But, this is not enough as the attack chain can be constructed in many other ways. Refer,

https://github.com/frohoff/ysoserial/tree/master/src/main/java/ysoserial/payloads

Solution 2 : Whitelisting By overriding the ObjectStream with a "SecureObjectStream", which validates for classes that are actually expected by the application.

Again, this doesn't negate the attacks completely. There is a RCE using jre7u21 and a Denial of Service attack using HashSets.

Solution 3 : Turn off deserialization The best one yet.

Question

In cases where deserialization cannot be neglected, is there a better way to validate and stop the bad data before it explodes other than black & white lists?

Answer 1

First, you need to think of the risk and who gets the serialized data. An internal admin interface with only 3 super-admins able to access it, does not require the same attention as a public website. In the first case, you might even not fix it and settle with the compensating controls. Second, you need to prioritize your suggestions: turning off serialization is the best option as it eliminates the risk. White listing specific classes is the second best and should be chosen if serialization cannot be turned off, but blacklisting is not recommended as you won't think of all of the options and it would be bypassed. I wouldn't consider blacklisting as a valid solution. Another possible solution, depending on the use-case, is encryption and\or signing (HMAC) of the serialized data. In .NET you have the Viewstate that can be used for deserialization attacks to take over it, but if it is signed or encrypted in a proper manner, you cannot modify it, so this is another valid solution. So you can choose one of these 3 (excluding blacklisting).