-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Future of the IFormatter infrastructure, safe polymorphic deserialization (not just BinaryFormatter) #50909
Comments
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
I didn't commit to that plan, only stated that it was one possible course of action. At this time we don't have such a serializer funded.
Neither of those types would be safe given the way |
If you mean the possibly out-of-range non-validated field values (eg. invalid |
Just a few additional thoughts. I'm starting to believe that actually all types that are currently serializable in .NET 5 can be made secure for We can divide the
This could definitely restore the 'I'm safe to be serialized by an Note for 3.b: I don't know whether other And of course, the points in my opening post still apply. So (1) a |
The
|
Ah, ok. I didn't review it just saw the |
In the meantime I realized that making serializable types safe is just one more necessary but still not sufficient condition to make the whole deserialization safe.
I try to build these protections into my serializer in So just back to the original topic: I don't mind if |
FYI: I fixed the possible
As for strings, I have to correct myself: |
Tagging subscribers to this area: @dotnet/area-system-runtime Issue DetailsAs we know, In #29976 he also mentions that a "safe" formatter (quotes from him) will be also implemented and it will be available in a separate NuGet package along with the obsoleted In this issue I would like to propose a generic way for resolving types by a serializer, and I would like to clarify the future of the If I'm not mistaken there are two requirements that must be fulfilled to make any polymorphic serializer safe:
Due to point 1.) the .NET Framework cannot be considered safe because it has potentially dangerous serializable types in As for point 2.), the current implementation of
Actually this is the error message from my own But even But please do not move the And finally, I can't really support the idea that totally harmless new types (such as
|
Closing this issue since no action is required on behalf of the libraries team. |
And what is the decision then? This was my suggestion:
|
The Existing APIs like |
As we know,
BinaryFormatter
is being obsoleted in the upcoming .NET versions as it is a security risk (see Levi's excellent design document about the topic).In #29976 he also mentions that a "safe" formatter (quotes from him) will be also implemented and it will be available in a separate NuGet package along with the obsoleted
BinaryFormatter
.In this issue I would like to propose a generic way for resolving types by a serializer, and I would like to clarify the future of the
IFormatter
infrastructure itself.If I'm not mistaken there are two requirements that must be fulfilled to make any polymorphic serializer safe:
Due to point 1.) the .NET Framework cannot be considered safe because it has potentially dangerous serializable types in
mscorlib.dll
andSystem.dll
. Though a customIFormatter
implementation may contain special handling for known potentially dangerous types such asTempFileCollection
(delete files attack) orStructuralEqualityComparer
(DoS attack). Starting with .NET Core these types are not serializable anymore, andTempFileCollection
is not even part of the core assemblies as it has been moved into a separate NuGet package.As for point 2.), the current implementation of
BinaryFormatter
loads all assemblies automatically that are referred in the serialization stream, which is a huge security issue (as illustrated in this video), therefore it cannot be considered safe even in .NET Core and above. But it does not mean it cannot be prevented by a safe type resolving logic. It could then throw an exception like this:Actually this is the error message from my own
IFormatter
implementation when safe mode is enabled. And this is how all polymorphic serializers should work (including text-based ones, eg. XML/JSON) when there is no custom control applied such as aSerializationBinder
.But even
BinaryFormatter
has totally safe usages: deep cloning objects, creating in-memory snapshots for undo/redo, etc. I understand that it is much more often misused than not so after all I can understand if it will be moved into a separate package.But please do not move the
IFormatter
infrastructure itself (including all attributes, interfaces,GetUninitializedObject
and so on) so it still will be possible to create (safely) serializable types and also safe(r) formatters without the need of referencing an external package, which btw. would load also the obsoleteBinaryFormatter
even it's not needed.And finally, I can't really support the idea that totally harmless new types (such as
Date
andTimeOfDay
) should not be[Serializable]
. Obviously, in the .NET Framework it was too generously (mis)used so it lost it's 'I'm safe to be used by formatters' meaning, but at least this was fixed in .NET Core. And forcing users to disable safe mode to be able to serialize such types by formatters would just weaken the whole infrastructure even more.The text was updated successfully, but these errors were encountered: