zyanfx / safedeserializationhelpers

:japanese_ogre: Fixes known BinaryFormatter deserialization vulnerabilities

Zyan.SafeDeserializationHelpers

This tiny library tries to fix several known BinaryFormatter vulnerabilities. When a malicious payload is detected, the library throws an UnsafeDeserializationException instead of deserializing the data that is able to produce bad side effects.

Deserializing the untrusted data is dangerous

It's proven that deserialing arbitrary payloads under certain conditions can trigger code execution. BinaryFormatter, DataContractSerializer, XmlSerializer, as well as several widely used JSON serializers are known to be vulnerable.

See ysoserial.net project for details.

Code sample

// unsafe: deserialization can trigger arbitrary code execution
var fmt = new BinaryFormatter();
var object = fmt.Deserialize(stream);

// safe: deserialization is guarded against known vulnerabilities
var fmt = new BinaryFormatter().Safe();
var object = fmt.Deserialize(stream);

Usage

1. Install Zyan.SafeDeserializationHelpers nuget package.
2. Use new BinaryFormatter().Safe() instead of just new BinaryFormatter().
3. For .NET Remoting projects, use safe versions of the binary formatter sinks:
   • Replace BinaryClientFormatterSinkProvider with SafeBinaryClientFormatterSinkProvider.
   • Replace BinaryServerFormatterSinkProvider with SafeBinaryServerFormatterSinkProvider.
4. Make sure to test your project against payloads produced by ysoserial.net gadgets.

Known vulnerabilities supported by the library

• ActivitySurrogateSelector gadget by James Forshaw (loads an assembly and executes arbitrary code).
• PSObject gadget by Oleksandr Mirosh and Alvaro Munoz. Target must run a system not patched for CVE-2017-8565.
• TypeConfuseDelegate gadget by James Forshaw (runs any process using Process.Start delegate).
• DataSet gadget by James Forshaw (unsafe BinaryFormatter deserialization).
• WindowsIdentity gadget by Levi Broderick (unsafe BinaryFormatter deserialization).

References

• Exploiting .NET Managed DCOM by James Forshaw
• Are you my Type? by James Forshaw
• Attacking .NET serialization by Alvaro Munoz
• Friday the 13th: JSON Attacks by Alvaro Munoz and Oleksandr Mirosh
• Severe Deserialization Issues Also Affect .NET, Not Just Java by Catalin Cimpanu
• ysoserial.net exploit collection by Alvaro Munoz

Thanks

• Markus Wulftange — for bringing up the problem to my attention
• James Forshaw — for the great blog posts, papers and talks on the subject
• Alvaro Munoz, Oleksandr Mirosh — for the awesome educational ysoserial.net project
• Chris Frohoff — for the original ysoserial Java project
• Levi Broderick — for more malicious gadgets

License

MIT License.

safedeserializationhelpers's Issues

Support for .NET Standard

Hi yallie,

is is possible/necessary to target the project to .NET Standard 2.0 or is the standard framework safe?

Many greetings
heikar

.NET 2.0 target

Let's try retargeting for .NET 2.0 instead of the current .NET 3.5.
.NET 2.0 is needed for the Genuine Channels project.

Replace custom exception with SecurityException

Custom exception requires Zyan.SafeDeserializationHelpers assembly to be deserialized. When the assembly is absent on the client side, the exception cannot be deserialized and is replaced with SerializationException which is kinda confusing.

Throwing a generic SecurityException instead of the custom UnsafeDeserializationException looks like a good compromise to me.