Is binary serialization inherently unsafe?

Question

Microsoft warns against using BinaryFormatter (they write that there is no way to make the de-serialization safe).

Applications should stop using BinaryFormatter as soon as possible, even if they believe the data they're processing to be trustworthy.

I don't want to use XML or Json -based solutions (which are what they refer to). I am concerned about file size and preserving the object graph.

If I were to write my own methods to traverse through my object graph and convert the objects to binary could that be made safely or is it something specifically with converting from binary that makes it inherently more dangerous that text?

Answer 1

Are there binary (non-XML and non-JSON) alternatives to BinaryFormatter ?

This question feels like it leads to answers that will be more opinion-based.

I'm sure there are a lot of libraries out there, but perhaps the best known alternative is Protocol Buffers (protobuf). It's a Google library, so it gets plenty of development and attention. However, not everyone agrees that using protobuf for generic binary serialization is the best thing to do.

Follow this discussion about BinaryFormatter on the github for dotnet if you want more info; it discusses the general problem with BinaryFormatter , as well as using protobuf as an alternative.

Can I create my own secure binary serialization system?

Yes. That said, the real question should be: 'is it worth my time to do so?'

See this link for the wind-down plan for BinaryFormatter : https://github.com/dotnet/designs/pull/141/commits/bd0a0661f9d248ed31a354d27ad026efd6719690

At the very bottom you will find:

Why not make BinaryFormatter safe for untrusted payloads?

The BinaryFormatter protocol works by specifying the values of an object's raw instance fields. In other words, the entire point of BinaryFormatter is to bypass an object's typical constructor and to use private reflection to set the instance fields to the contents that came in over the wire. Bypassing the constructor in this fashion means that the object cannot perform any validation or otherwise guarantee that its internal invariants are satisfied. One consequence of this is that BinaryFormatter is unsafe even for seemingly innocuous types such as Exception or List<T> or Dictionary<TKey, TValue> , regardless of the actual types of T , TKey , or TValue . Restricting deserialization to a list of allowed types will not resolve this issue.

The security issue isn't with binary serialization as a concept; the issue is with how BinaryFormatter was implemented.

You could design a secure binary deserialization system, if you wanted. If you have very few messages being sent, and you can tightly control which types are deserialized, perhaps it's not too much effort to make a secure system.

However, for a system flexible enough to handle many different use cases (eg many different types that can be deserialized), you may find that it takes a lot of effort to build in enough safety checks.

---

FWIW, you likely will never reach the performance levels of BinaryFormatter with a secure system that offers the same widespread utility (use cases), since BinaryFormatter 's speed comes (in part) from having very few safety features . You might approach such performance levels with a targeted, small system with a narrow set of use cases.