TypeNameHandling caution in Newtonsoft Json

Question

On this link, in remarks section it's mentioned that:

TypeNameHandling should be used with caution when your application deserializes JSON from an external source. Incoming types should be validated with a custom SerializationBinder when deserializing with a value other than TypeNameHandling.None.

In what cases JSON from external source would be harmful if serialized/deserialized with TypeNameHandling.All? A working example would be appreciated.

Answer 1

When deserialize with TypeNameHandling.All and without a SerializationBinder checks json.net will try to create a instace of the type that comes as metadata in the JSON.

public class Car
{
    public string Maker { get; set; }
    public string Model { get; set; }
}

{
   "$type": "Car",
   "Maker": "Ford",
   "Model": "Explorer"
} //create a Car and set property values

But an attacker could send you dangerous types that exist in your code or in the framework.

i.e. from here System.CodeDom.Compiler.TempFileCollection is a serializable class whose purpose is to maintain a list of temporary files which resulted from a compilation process and delete them when they are no longer needed. To ensure that the files are deleted the class implements a finalizer that will be called when the object is being cleaned up by the Garbage Collector. An attacker would be able to construct a serialized version of this class which pointed its internal file collection to any file on a victims system. This will be deleted at some point after deserialization without any interaction from the deserializing application.

    [Serializable]
    public class TempFileCollection
    {
       private Hashtable files;
       // Other stuff...

       ~TempFileCollection()
       {
         if (KeepFiles) {return}
         foreach (string file in files.Keys)
         {
            File.Delete(file);
         }
       }
    }

   {
       "$type": "System.CodeDom.Compiler.TempFileCollection",
       "BasePath": "%SYSTEMDRIVE",
       "KeepFiles": "False",
       "TempDir": "%SYSTEMROOT%"
    } // or something like this, I just guessing but you got the idea

Answer 2

Some additional attack gadgets have been identified in Alvaro Muñoz & Oleksandr Mirosh's blackhat paper https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf. These are:

• System.Configuration.Install.AssemblyInstaller - Attack vector: execute payload on assembly load.

• System.Activities.Presentation.WorkflowDesigner - Attack vector: execute static method during parsing of Xaml payload.

• System.Windows.ResourceDictionary - Attack vector: an attacker sends payload with URL to controlled server, this server responds with Xaml payload and ContentType = application/xaml+xml and target server will execute desired static method during parsing of Xaml payload.

• System.Windows.Data.ObjectDataProvider - Attack vector: 1) call any method of unmarshaled object; 2) We can call parametrized constructor of desired type with controlled parameters; 3) call any public method including static ones with controlled parameters.

• System.Windows.Forms.BindingSource - Attack vector: arbitrary getter call.

• Microsoft.Exchange.Management.SystemManager.WinForms.ExchangeSettingsProvider - Attack vector: it allows jumping from setters to nested BinaryFormatter deserialization.

Note however that the attack gadget type must be compatible with (assignable to) the expected type being deserialized for the attack to succeed. This is always true when the expected type is object or dynamic and may be true in other situations. See External json vulnerable because of Json.Net TypeNameHandling auto? for details.