.NET September 2022 Updates - .NET 6.0.9 and .NET Core 3.1.29

[dcwhittaker]

Release Notes
6.0.9
3.1.29

Please report any issues you find either by responding to this issue, creating a new issue or creating a new issue in one of the following repos:

• dotnet/aspnetcore - for ASP.NET Core questions
• dotnet/efcore - for Entity Framework Core questions
• dotnet/sdk - for CLI tools and questions
• dotnet/runtime - for runtime, API, or installer issues and questions
• dotnet/winforms - for WinForms issues
• dotnet/wpf - for WPF issues
• nuget/home - for NuGet questions and issues

Distro	6.0.9	3.1.29
Ubuntu 18.04
Ubuntu 20.04
Ubuntu 22.04
Centos 7
Debian 10
Debian 11
Fedora 34
OpenSUSE 15
Oracle

Note: This list refers to the Microsoft-provisioned feeds (packages.microsoft.com) and does not in any way represent direct availability in distros (eg RHEL, Fedora).

Known Issues

If there are any more issues with this release we will track them here and check issues off as they're resolved. See the linked issues for details on progress and resolution details.

[gaborposz]

Hello,
At my company after every .NET Core patch release we have to assess the actual security vulnerabilities whether we shall update the used .NET Core version or not. We must make a through decision because the update is very expensive, as we are developing a medical software platform with very strict regulatory system, and dozens of products are affected all around the world. However, the information provided about the vulnerabilities is very limited, usually inadequate to draw any conclusion from it.

For example:
“A denial of service vulnerability exists in ASP.NET Core 3.1 and .NET 6.0 where a malicious client could cause a stack overflow which may result in a denial of service attack when an attacker sends a customized payload that is parsed during model binding.”

What kind of payload? What kind of model? Which APIs are affected? In which call stack the StackOverflowException is thrown? Will it kill only the affected web application, or also the web server? What the attacker needs to do to create such a payload? And so on…

I understand that Microsoft wants to disclose as little information about the vulnerabilities as possible, but on our side it is not enough to create an “environmental” CVSS score, and possibly postpone the update if it is not applicable for us.
It could help a lot of if it was better described, or at least the affected APIs (and/or the fixing commit) are referenced.

[blowdart]

@gaborposz as you rightfully point out we try to keep details as generic as possible, to reduce the risk of immediate exploitation (although of course once we tag the commit against the issue folks can figure everything out).

If we start delving into details we increase the risk to a proportion of customers who match the exploited surface area. and it is hard to put a percentage or number against those folks we've just targeted.

On the other hand, if there's an easy mitigation we do list that. For example, if an exploit targeted IIS but didn't affect Kestrel we do say something in mitigations to that effect. If the exploit affected JSON parsing or HTML form parsing we'd be specific about that.

If there's no "easy" mitigation or the wording is wonderfully vague, in my opinion. consider patching as soon as possible.

Admittedly, as the security PM for .NET and other things in devdiv that's always going to be my opinion, and the vague wording is very much on me, not anyone else.

One other thing to consider is that not all fixes will receive CVEs. Internal finds which are considered difficult to exploit may be fixed as part of the normal patching process. Those, of course, may get a CVE if someone works it out and it ends up under active attack.

If you're under the regulatory constraints that you indicate I'd reach out to your Microsoft account manager, if you have one, to ask them for more details. We've done this for a number of customers under NDA.

[neanderson]

Have there been any reports of netsh.exe crashing on Windows 11 after installing this update? I support a product that uses Netsh to modify the network, and we've encountered several cases where netsh.exe crashes repeatedly on Windows 11. Rolling back this update seems to resolve the problem.

[dcwhittaker]

Closed in favor of #7864