Repository navigation
Microsoft Security Advisory CVE-2023-29331: .NET Denial of Service vulnerability #87498
Description
Microsoft Security Advisory CVE-2023-29331: .NET Denial of Service vulnerability
Executive summary
Microsoft is releasing this security advisory to provide information about a vulnerability in .NET 7.0 and .NET 6.0. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.
A vulnerability exists in .NET when processing X.509 certificates that may result in Denial of Service.
Details: KB5025823
Announcement
Announcement for this issue can be found at dotnet/announcements#257
Mitigation factors
Microsoft has not identified any mitigating factors for this vulnerability.
Affected software
- Any .NET 7.0 application running on .NET 7.0.5 or earlier.
- Any .NET 6.0 application running on .NET 6.0.16 or earlier.
If your application uses the following package versions, ensure you update to the latest version of .NET.
.NET 7
| Package name | Affected version | Patched version |
|---|---|---|
| Microsoft.Windows.Compatibility | >= 7.0.0, < 7.0.1 | 7.0.3 |
| System.Security.Cryptography.Pkcs | >= 7.0.0, < 7.0.1 | 7.0.2 |
| Microsoft.NetCore.App.Runtime.linux-arm | >= 7.0.0, < 7.0.5 | 7.0.7 |
| Microsoft.NetCore.App.Runtime.linux-arm64 | >= 7.0.0, < 7.0.5 | 7.0.7 |
| Microsoft.NetCore.App.Runtime.linux-musl-arm | >= 7.0.0, < 7.0.5 | 7.0.7 |
| Microsoft.NetCore.App.Runtime.linux-musl-arm64 | >= 7.0.0, < 7.0.5 | 7.0.7 |
| Microsoft.NetCore.App.Runtime.linux-musl-x64 | >= 7.0.0, < 7.0.5 | 7.0.7 |
| Microsoft.NetCore.App.Runtime.linux-x64 | >= 7.0.0, < 7.0.5 | 7.0.7 |
| Microsoft.NetCore.App.Runtime.osx-arm64 | >= 7.0.0, < 7.0.5 | 7.0.7 |
| Microsoft.NetCore.App.Runtime.osx-x64 | >= 7.0.0, < 7.0.5 | 7.0.7 |
| Microsoft.NetCore.App.Runtime.win-arm | >= 7.0.0, < 7.0.5 | 7.0.7 |
| Microsoft.NetCore.App.Runtime.win-arm64 | >= 7.0.0, < 7.0.5 | 7.0.7 |
| Microsoft.NetCore.App.Runtime.win-x64 | >= 7.0.0, < 7.0.5 | 7.0.7 |
| Microsoft.NetCore.App.Runtime.win-x86 | >= 7.0.0, < 7.0.5 | 7.0.7 |
.NET 6
| Package name | Affected version | Patched version |
|---|---|---|
| Microsoft.Windows.Compatibility | >= 6.0.0, < 6.0.4 | 6.0.6 |
| System.Security.Cryptography.Pkcs | >= 6.0.0, < 6.0.2 | 6.0.3 |
| Microsoft.NetCore.App.Runtime.linux-arm | >= 6.0.0, < 6.0.16 | 6.0.18 |
| Microsoft.NetCore.App.Runtime.linux-arm64 | >= 6.0.0, < 6.0.16 | 6.0.18 |
| Microsoft.NetCore.App.Runtime.linux-musl-arm | >= 6.0.1, < 6.0.16 | 6.0.18 |
| Microsoft.NetCore.App.Runtime.linux-musl-arm64 | >= 6.0.0, < 6.0.16 | 6.0.18 |
| Microsoft.NetCore.App.Runtime.linux-musl-x64 | >= 6.0.0, < 6.0.16 | 6.0.18 |
| Microsoft.NetCore.App.Runtime.linux-x64 | >= 6.0.0, < 6.0.16 | 6.0.18 |
| Microsoft.NetCore.App.Runtime.osx-arm64 | >= 6.0.0, < 6.0.16 | 6.0.18 |
| Microsoft.NetCore.App.Runtime.osx-x64 | >= 6.0.0, < 6.0.16 | 6.0.18 |
| Microsoft.NetCore.App.Runtime.win-arm | >= 6.0.0, < 6.0.16 | 6.0.18 |
| Microsoft.NetCore.App.Runtime.win-arm64 | >= 6.0.0, < 6.0.16 | 6.0.18 |
| Microsoft.NetCore.App.Runtime.win-x64 | >= 6.0.0, < 6.0.16 | 6.0.18 |
| Microsoft.NetCore.App.Runtime.win-x86 | >= 6.0.0, < 6.0.16 | 6.0.18 |
Advisory FAQ
How do I know if I am affected?
If you have a runtime or SDK with a version listed, or an affected package listed in affected software, you're exposed to the vulnerability.
How do I fix the issue?
- To fix the issue please install the latest version of .NET 6.0 or .NET 7.0. If you have installed one or more .NET SDKs through Visual Studio, Visual Studio will prompt you to update Visual Studio, which will also update your .NET SDKs.
- If you are using one of the affected packages, please update to the patched version listed above.
- If you have .NET 6.0 or greater installed, you can list the versions you have installed by running the
dotnet --infocommand. You will see output like the following;
.NET Core SDK (reflecting any global.json):
Version: 6.0.300
Commit: 8473146e7d
Runtime Environment:
OS Name: Windows
OS Version: 10.0.18363
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\6.0.300\
Host (useful for support):
Version: 6.0.5
Commit: 8473146e7d
.NET Core SDKs installed:
6.0.300 [C:\Program Files\dotnet\sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download
- If you're using .NET 7.0, you should download and install Runtime 7.0.7 or SDK 7.0.106 (for Visual Studio 2022 v17.4) from https://dotnet.microsoft.com/download/dotnet-core/7.0.
- If you're using .NET 6.0, you should download and install Runtime 6.0.18 or SDK 6.0.312 (for Visual Studio 2022 v17.2) from https://dotnet.microsoft.com/download/dotnet-core/6.0.
.NET 6.0 and and .NET 7.0 updates are also available from Microsoft Update. To access this either type "Check for updates" in your Windows search, or open Settings, choose Update & Security and then click Check for Updates.
Once you have installed the updated runtime or SDK, restart your apps for the update to take effect.
Additionally, if you've deployed self-contained applications targeting any of the impacted versions, these applications are also vulnerable and must be recompiled and redeployed.
Other Information
Reporting Security Issues
If you have found a potential security issue in .NET 6.0 or .NET 7.0, please email details to secure@microsoft.com. Reports may qualify for the Microsoft .NET Core & .NET 5 Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at https://aka.ms/corebounty.
Support
You can ask questions about this issue on GitHub in the .NET GitHub organization. The main repos are located at https://github.com/dotnet/runtime and https://github.com/dotnet/aspnet/. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue.
Disclaimer
The information provided in this advisory is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.
External Links
Revisions
V1.0 (June 13, 2023): Advisory published.
Version 1.0
Last Updated 2023-06-13
Activity
johnthcall commentedon Jun 15, 2023
Is there a reason a new version of System.Security.Cryptography.Xml requiring System.Security.Cryptography.Pkcs >= 7.0.2 was not introduced? Or is that not standard practice for this type of fix.
franklixuefei commentedon Jun 25, 2023
looks like it's resolved https://support.microsoft.com/en-us/topic/kb5028608-change-in-how-net-framework-runtime-imports-x-509-certificates-abc64f77-5f7b-449b-9285-4d9a982fc368
joshihrn commentedon Jul 13, 2023
Even after using latest SDK for .net 6.0, it is still giving Prisma issue during build, is there any way to resolve that?
peterkiss1 commentedon Jul 19, 2023
Any chance to get updated System.Security.Cryptography.Xml packages for .NET 6 and 7?
Probably a few projects are waiting for this for example: .NET WCF
jerryk414 commentedon Sep 5, 2023
@ericstj @TravisEz13 @rbhanda
This question has been asked multiple times but nobody has responded.
Can you please release a new version of
System.Security.Cryptography.Xml- this package brings in v7.0.0 ofSystem.Security.Cryptography.Pkcsas a transient dependency and forces consumers to have to explicitly reference thePkcspackage in order to get this security update.ericstj commentedon Sep 5, 2023
For packages built out of dotnet/runtime we only ship a new version of a package if the package itself requires changes. We do not ship new versions of library packages just to update dependencies. Should the package need to ship in the future for some other reason it will have the updated dependency.
jerryk414 commentedon Sep 5, 2023
@ericstj I understand how that, in general, package releases are frequent enough that that policy is probably fine most of the time. But it's been almost 3 months and the latest version of
System.Security.Cryptography.Xmlstill ships with security vulnerabilities out-of-the-box.What happens if this package does have a new version shipped for 1 year? 2 years? etc.
It's also problematic because, unless consumers are actively looking at their transient dependencies and running security analysis on those, they are not going to be aware that even the latest version of that package is insecure.
ericstj commentedon Sep 6, 2023
It does not have a vulnerability itself. It references a minimum version of another component which has a vulnerability.
It will have a new version shipped annually with the next major release of .NET.
It's a contradiction to care about security but not care about it for transitive dependencies. If one takes that perspective, they will either leave themselves unpatched because some component they don't control doesn't update - or delay the time to being patched until everyone in their closure can ship a new version. It's our position that relying on all direct dependencies to update is bad practice.
Component Governance helps folks identify transitive dependencies that need an update and central package versioning with transitive pinning helps you represent those updates in a way that's not too burdensome on the repository.
If you would still like a change in the policy here, you can open a new issue or discussion to track that conversation. I'll reiterate though, that we only control what happens for our packages - and based on the way the ecosystem/NuGet works one must care about transitive dependencies to ensure they are truly patched.
jerryk414 commentedon Sep 6, 2023
I understand the stance and how taking the opposite approach would be burdensome as there could be many updates necessary all the time. Although there are tools built to solve this problem (see dependabot).
I just think that taking this stance could be too far in the direction of reduced responsibility. It's like selling a car with a flat tire and saying you should be checking all your tires before you take it on the road. It's technically not wrong, but it isn't a great experience for the consumer.
I don't disagree that you should be checking transient dependencies, we do just that and that's how i ended up here. I just don't like that we're having to explicitly reference some newer version of a library because of this issue, even though the issue has been long since fixed. I think it could be better.
If only there was a way to set a overall project level policy to have nuget resolve the latest minor/patch version of transients... 🤔