3

I've heard there are safety questions over the BinaryFormatter.

I send user-generated files to the server from the client. These are serialized classes that are then read by the server.

From my understanding of the above link, this is dangerous. But I've tried sending disposable classes, and even tried a class that implemented ISerilizable. But both were rejected due to the server not knowing the source assembly.

[Serializable] public class Ship : ISerializable { public Ship() { } public Ship(SerializationInfo info, StreamingContext context) { Console.WriteLine("test"); } public void GetObjectData(SerializationInfo info, StreamingContext context) { } }

So how could a client successfully get code into my server via this vector? By faking the namespace name and public key causing the server to try deserialise it, thus running the above code? Or are there more subtle ways to do it?

This feature is a core fundamental to my game unfortunately so I want to be careful.

Improve this question
3
  • They can probably send you any of your own classes that happen to be marked Serializable. I think that's dangerous. Commented Jan 8, 2014 at 8:49
  • Is it your requirement to use the BinaryFormatter, or to serialize your data? Or to serialize your data in Binary? Commented Jan 8, 2014 at 8:51
  • 4
    Serialization works on data, not code. If your code is vulnerable to malicious input, then yes, this could be another way to attack it - just like any other way of injecting malicious data. Besides, the answers to the original post were mostly speculation, inapplicable comments on Java serialization or really contrived examples Commented Jan 8, 2014 at 8:53

3 Answers 3

Reset to default
10

I know this is an old question but I'm not quite satisfied with the accepted answer.

Serialization works on data, not code. [...] It does NOT extract any code from the payload.

It's not that simple. BinaryFormatter uses assembly qualified names to identify types. During the deserialization those type names are resolved by Type.GetType, which happily loads any assemblies. Therefore, a manipulated stream can load a prepared assembly, whose module initializer is immediately executed (but the malicious code can be placed in a serialization constructor or [OnDeserializing]/[OnDeserialized] method, too). This video demonstrates how to exploit this to open a PowerShell and a web page in a browser.

In any case the answers to the original post were mostly speculation, comments on Java serialization that's not really relevant to .NET or really contrived examples.

Maybe just because the answer is too old, but today there are a lot of known BinaryFormatter attacks. Some examples:

  • TempFileCollection can be exploited to delete files (only in .NET Framework). This is also mentioned in the linked video (and also in the post linked in the question).
  • StructurelEqualityComparer can be used to cause a StackOverflowException or a hopelessly slow hash code calculation (DoS attack). Starting with .NET Core this type is not serializable anymore.
  • A lot of [Serializable] types that don't implement ISerializable (so they are restored just by setting their fields) can be initialized with invalid data.
  • Even most types that implement ISerializable don't validate the incoming SerializationInfo for all possible attacks. For example, Dictionary<TKey, TValue> can throw an OutOfMemoryException if the value of the HashSize entry is manipulated.
  • But BinaryFormatter is vulnerable at a deeper level, too. For example, arrays are handled internally (and it cannot be even overridden by a surrogate selector) and a manipulated length information can also cause an OutOfMemoryException.

I actually believed that BinaryFormatter can be made safe. I even opened an issue about this topic here: https://github.com/dotnet/runtime/issues/50909

But considering that security was never in focus when serializable types were implemented and it would be an enormous task to fix all these issues I can understand that BinaryFormatter will be obsoleted in the future versions.

And though I introduced a SafeMode option in my binary serializer, it cannot be completely safe as long as the serializable types themselves are vulnerable (EDIT: in the latest versions you must enlist the expected custom types in SafeMode so you cannot just deserialize any type from the already loaded assemblies). To be actually completely safe you can restrict yourself to use the natively supported types only (which is also good to produce a very compact payload), or at least add a proper validation to your custom serializable types. See the Security Note at the description of the BinarySerializationFormatter class for more details.

Verdict: BinaryFormatter is safe only when both serialization and deserialization is performed in the same process. In any other case you need to implement some additional security (eg. by signing the stream cryptographically) to be completely safe.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Seven years ago I'd have complained you didn't answer my question, now I realise my question was itself wrong. You're completely right that my base assumption that serialisation sent the whole class was wrong, and yet there are many other ways to abuse the BinaryFormatter in other ways. Thank you.
2

Serialization works on data, not code. A deserializer extracts the data from the payload you provide, consturcts a new object instance and sets the object's values from the extracted data. It does NOT extract any code from the payload.

If your code is vulnerable to malicious input in the first place, then yes, deserialization could be another way to attack it - just like any other way of injecting malicious data.

For example, if you construct SQL statements by concatenating strings, you will be vulnerable to SQL injection attack whether the strings come from user input or deserialized data. The way to fix this is to use parameterized queries, not avoid deserialization or try to sanitize the user's input.

In any case the answers to the original post were mostly speculation, comments on Java serialization that's not really relevant to .NET or really contrived examples.

Improve this answer

Comments

1

The BinaryFormatter serializes fields and not methods.

The only way to transmit and load unknown code is to:

  1. Receive an assembly and load it using Assembly.Load.
  2. Use a CodeDomProvider to emit IL at runtime.
Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.