Microsoft is removing the BinaryFormatter class from .NET 9 – the forthcoming version to be released later this year – because of well-known security issues and despite widespread use, but is leaving it as-is in the Windows-only .NET Framework.

The BinaryFormatter class is used to serialize and deserialize objects to an efficient binary format, for saving to storage or streaming across a network. It has been a known security risk for more than a decade, because it will faithfully deserialize objects even if they have methods like DeleteAllMyData, as explained by Microsoft principal security program manager Barry Dorrans earlier this year. Dorrans conceded that Microsoft’s own products – including Exchange, SharePoint and Azure DevOps – had formerly suffered remote code execution vulnerabilities thanks to use of BinaryFormatter, and that the issues with the class are not fixable.

The risks were known even when .NET Core 1.0, the first cross-platform version, was released in 2016. That’s why the class was omitted. However, “customer demand brought it back to .NET Core 1.1,” Dorrans wrote, because at the time there was no clear alternative. The documentation warns that the class “can’t be made secure” but it has been possible to use it by setting flags. In .NET 9 it will always raise an exception, unless developers install an unsupported NuGet package that restores it. The unsafe class will remain in .NET Framework. 

Why will Microsoft still make it possible to use BinaryFormatter? The fact that it lives on in .NET Framework, and can be added to .NET 9, means it will be relatively easy to continue using insecure code. One developer on GitHub observed that the risk is that users will “just go with the new package and put up a rule for scanners that will accept any issue raised by the package, under the thought ‘we will migrate in future’ but which gets delayed for potentially forever till .NET Framework is officially unsupported.”

The reply by Dorrans gives some insight into the problem faced by Microsoft. “When we released .NET Core 1.0, with BinaryFormatter removed entirely, someone took the code from .NET Framework, built it into a NuGet package and released it. Additionally, there were a lot of emails from large customers to management stating people couldn’t migrate from Framework because it was missing,” he explained.

It appears from this GitHub discussion that .NET Framework, which is still widely used, is beyond fixing – not only because of customer code, but also because built-in frameworks including Windows Forms and Web Forms use BinaryFormatter. 

The common question from security-conscious developers is how to migrate away from BinaryFormatter. Microsoft has a migration guide with four options: System.Text.Json, DataContractSerializer, MessagePack, or protobuf-net. The latter two are also binary serializers, but safer to use.

What about the .NET Core variants of Windows Forms and Windows Presentation Foundation? The documentation states that “starting with .NET 9, Windows Forms and WPF use a subset of the BinaryFormatter implementation internally” for scenarios such as clipboard drag-and-drop, and storing and loading resources in Visual Studio. The docs go on to claim that “while BinaryFormatter’s risks cannot be addressed in general-purpose serialization/deserialization, measures have been taken to mitigate the risks in these very specific use cases with a known set of types.”

This sounds like Microsoft is not altogether taking the medicine it recommends to others – but it may not be as bad as that. Principal program manager Immo Landwerth said that “what we did for WinForms is implement a ‘BinaryFormatter’ payload (formally called NRBF) reader and writer that is being used to write the binary representation for the most common resource types (such as strings and images). While the format being read and produced is NRBF, it’s not using BinaryFormatter.” NRBF is .NET Remoting Binary Format, which is used by BinaryFormatter.

He added that the payload reader is available as a package that can be used to read NRBF, following which a new NrbfDecoder class can be used to decode the content safely. It sounds like this should be part of the migration guide, since it covers the scenario where applications have to read objects created by BinaryFormatter. 

The fact that Microsoft itself has had to devise these workarounds also demonstrates that migration is not always straightforward – hence the fear that some .NET developers will take the easy and insecure path of continuing to use BinaryFormatter, despite the risks.