Dynamic Code Evaluation: Unsafe Deserialization

Deserializing user-controlled object streams at runtime can allow attackers to execute arbitrary code on the server, abuse application logic, and/or lead to denial of service.

.NET serialization turns object graphs into byte or XML streams that contain the objects themselves and the necessary metadata to reconstruct them from the stream. Developers can create custom code to aid in the process of deserializing .NET objects, where they can replace the deserialized objects with different objects, or proxies. The customized deserialization process takes place during objects reconstruction, before the objects are returned to the application and cast into expected types. By the time developers try to enforce an expected type, code may have already been executed.

Example 1: The following function takes a Stream object from a connection as input and deserializes it back to a .NET object. This then returns the result after casting it to a list of string objects:

...
List <string> Deserialize(Stream input)
{
  var bf = new BinaryFormatter();
  var result = (List <string>)bf.Deserialize(input); 
  return result;
}
...

For better understanding, Example 1 can be rewritten as the following:

Example 2:

...
List <string> Deserialize(Stream input)
{
  var bf = new BinaryFormatter();
  object tmp = bf.Deserialize(input);
  List <string> result = (List <string>)tmp;
  return result;
}
...

In Example 2, the deserialization operation will succeed as long as the input stream is valid, regardless of whether the type is List <string> or not.

Custom deserialization routines are defined in the serializable classes which need to be present in the bin folder or in the GAC and cannot be injected by the attacker, so the exploitability of these attacks depends on the classes available in the application environment. Unfortunately, common third party classes or even .NET classes can be abused to exhaust system resources, delete files, deploy malicious files, or run arbitrary code.