From 914ffbbfbd86702470b9fe294d8b26c494744604 Mon Sep 17 00:00:00 2001 From: Levi Broderick Date: Tue, 12 Nov 2024 14:34:40 -0800 Subject: [PATCH 1/2] Update binaryformatter-security-guide.md --- docs/standard/serialization/binaryformatter-security-guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/standard/serialization/binaryformatter-security-guide.md b/docs/standard/serialization/binaryformatter-security-guide.md index bc84a1bab2362..4bfc147375d4e 100644 --- a/docs/standard/serialization/binaryformatter-security-guide.md +++ b/docs/standard/serialization/binaryformatter-security-guide.md @@ -42,7 +42,7 @@ As a simpler analogy, assume that calling `BinaryFormatter.Deserialize` over a p `BinaryFormatter` was implemented before deserialization vulnerabilities were a well-understood threat category. As a result, the code does not follow modern best practices. The `Deserialize` method can be used as a vector for attackers to perform DoS attacks against consuming apps. These attacks might render the app unresponsive or result in unexpected process termination. This category of attack cannot be mitigated with a `SerializationBinder` or any other `BinaryFormatter` configuration switch. .NET considers this behavior to be ***by design*** and won't issue a code update to modify the behavior. -`BinaryFormatter.Deserialize` may be vulnerable to other attack categories, such as information disclosure or remote code execution. Utilizing features such as a custom may be insufficient to properly mitigate these risks. The possibility exists that a novel vulnerability will be discovered for which .NET cannot practically publish a security update. Consumers should assess their individual scenarios and consider their potential exposure to these risks. +`BinaryFormatter.Deserialize` may be susceptible to other attack categories, such as information disclosure or remote code execution. Utilizing features such as a custom may be insufficient to properly mitigate these risks. The possibility exists that an attacker will discover a novel exploit which bypasses existing mitigations. .NET does not commit to publishing patches in response to any such bypasses, and in fact developing or deploying such patches might be technically infeasible. Consumers should assess their individual scenarios and consider their potential exposure to these risks. We recommend that `BinaryFormatter` consumers perform individual risk assessments on their apps. It is the consumer's sole responsibility to determine whether to utilize `BinaryFormatter`. If you're considering using it, you should risk-assess the security, technical, reputation, legal, and regulatory consequences. From 4e22d5dca244e4dff0cb5e4684dead470b8fe555 Mon Sep 17 00:00:00 2001 From: Levi Broderick Date: Tue, 12 Nov 2024 16:07:25 -0800 Subject: [PATCH 2/2] PR feedback Co-authored-by: Genevieve Warren <24882762+gewarren@users.noreply.github.com> --- docs/standard/serialization/binaryformatter-security-guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/standard/serialization/binaryformatter-security-guide.md b/docs/standard/serialization/binaryformatter-security-guide.md index 4bfc147375d4e..28a667b1ac2b5 100644 --- a/docs/standard/serialization/binaryformatter-security-guide.md +++ b/docs/standard/serialization/binaryformatter-security-guide.md @@ -42,7 +42,7 @@ As a simpler analogy, assume that calling `BinaryFormatter.Deserialize` over a p `BinaryFormatter` was implemented before deserialization vulnerabilities were a well-understood threat category. As a result, the code does not follow modern best practices. The `Deserialize` method can be used as a vector for attackers to perform DoS attacks against consuming apps. These attacks might render the app unresponsive or result in unexpected process termination. This category of attack cannot be mitigated with a `SerializationBinder` or any other `BinaryFormatter` configuration switch. .NET considers this behavior to be ***by design*** and won't issue a code update to modify the behavior. -`BinaryFormatter.Deserialize` may be susceptible to other attack categories, such as information disclosure or remote code execution. Utilizing features such as a custom may be insufficient to properly mitigate these risks. The possibility exists that an attacker will discover a novel exploit which bypasses existing mitigations. .NET does not commit to publishing patches in response to any such bypasses, and in fact developing or deploying such patches might be technically infeasible. Consumers should assess their individual scenarios and consider their potential exposure to these risks. +`BinaryFormatter.Deserialize` might be susceptible to other attack categories, such as information disclosure or remote code execution. Utilizing features such as a custom might be insufficient to properly mitigate these risks. The possibility exists that an attacker will discover a novel exploit that bypasses existing mitigations. .NET does not commit to publishing patches in response to any such bypasses. In addition, developing or deploying such patches might be technically infeasible. You should assess your scenarios and consider your potential exposure to these risks. We recommend that `BinaryFormatter` consumers perform individual risk assessments on their apps. It is the consumer's sole responsibility to determine whether to utilize `BinaryFormatter`. If you're considering using it, you should risk-assess the security, technical, reputation, legal, and regulatory consequences.