Microsoft Security Advisory CVE-2020-1045 | Microsoft ASP.NET Core Security Feature Bypass Vulnerability

[blowdart]

Microsoft Security Advisory CVE-2020-1045 | Microsoft ASP.NET Core Security Feature Bypass Vulnerability

Executive summary

Microsoft is releasing this security advisory to provide information about a vulnerability in ASP.NET Core. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.

A security feature bypass vulnerability exists in the way Microsoft ASP.NET Core parses encoded cookie names.

The ASP.NET Core cookie parser decodes the cookie name which could allow a malicious attacker to use percent encoded characters to masquerade as a different cookie with different security features.

The security update addresses the vulnerability by fixing the way the ASP.NET Core cookie parser handles encoded names.

Announcement

Announcement for this issue can be found at dotnet/announcements#165

Mitigation factors

Microsoft has not identified any mitigating factors for this vulnerability.

Affected software

• Any .NET Core 3.1 application running on .NET Core 3.1.7 or lower
• Any .NET Core 2.1 application running on .NET Core 2.1.21 or lower

Please note that .NET Core 3.0 is now out of support and all applications should be updated to 3.1.

How do I know if I am affected?

If you have a runtime or SDK with a version listed in affected software you are exposed to the vulnerability.

How do I fix the issue?

To fix the issue please install the latest version of .NET Core 3.1. If you have installed one or more .NET Core SDKs through Visual Studio, Visual Studio will prompt you to update Visual Studio which will also update your .NET Core SDKs.

You can list the versions you have installed by running the dotnet --info command. You will see output like the following;

.NET Core SDK (reflecting any global.json):
 Version:   3.1.100
 Commit:    cd82f021f4

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.18363
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\3.1.100\

Host (useful for support):
  Version: 3.1.0
  Commit:  65f04fb6db

.NET Core SDKs installed:
  3.1.100 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

• You should download and install Runtime 3.1.8 or SDK 3.1.108 (for Visual Studio 2019 v16.4) or 3.1.402 (for Visual Studio 2019 v16.5 or later) from https://dotnet.microsoft.com/download/dotnet-core/3.1

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 Core, please email details to secure@microsoft.com. Reports may qualify for the .NET Core Bug Bounty. Details of the .NET Core Bug Bounty including terms and conditions are at https://aka.ms/corebounty.

Support

You can ask questions about this issue on GitHub in the .NET Core 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

CVE-2020-1045

Revisions

V1.0 (September 8, 2020): Advisory published.

Version 1.0

Last Updated 2020-09-08

[KalleOlaviNiemitalo]

According to #24264, the fix is in the Microsoft.AspNetCore.Http package. I think that means the issue also affects ASP.NET Core 2.1 on .NET Framework, rather than only .NET Core.

According to #23578 and AspNetKatana release 4.1.1, Microsoft.Owin is also affected. There, Microsoft.Owin 4.1.1 is the fixed package. As far as I can tell, the changes in the 4.1.1 versions of the other Microsoft.Owin.* packages are unrelated.

[Tratcher]

You're correct on both points. We'll get these clarified.

[deastr]

What about Asp.Net Core 1.x applications? Are they affected?

[Tratcher]

What about Asp.Net Core 1.x applications? Are they affected?

Yes, but they are out of support. As is 2.2 and 3.0.

[Indigo744]

Hello everyone,

Our project uses ASP.Net Core 2.1 targeting the .Net Framework 4.7.2.

We do not reference directly the Microsoft.AspNetCore.Http package, but it is a transitive dependency, in our case coming from Microsoft.AspNetCore.Server.IISIntegration and Microsoft.AspNetCore.Authentication.

Now my question is, how can I make sure I am using the latest Microsoft.AspNetCore.Http Nuget package even though I do not directly reference it?

Because looking at the output (DLL version and .config file), it seems we are still stuck on Microsoft.AspNetCore.Http version 2.1.1.

Are we suppose to wait for the parent package to update its dependencies?
If yes, how can we be sure the parent package will always update its dependencies? It looks like a security blind spot to me...

The parent packages seem to reference the dependency as Microsoft.AspNetCore.Http (>= 2.1.1), but how can I force the package manager to take the latest compatible patch 2.1.22?

Thank for your help...

[Tratcher]

Now my question is, how can I make sure I am using the latest Microsoft.AspNetCore.Http Nuget package even though I do not directly reference it?
The parent packages seem to reference the dependency as Microsoft.AspNetCore.Http (>= 2.1.1), but how can I force the package manager to take the latest compatible patch 2.1.22?

By adding a direct reference to the updated version of Microsoft.AspNetCore.Http.

[Indigo744]

By adding a direct reference to the updated version of Microsoft.AspNetCore.Http.

Well, thank you but you are kind of stating the obvious 😅

What I would like to know is if there is a better way to ensure we are running the latest compatible version available for all transitive dependencies, without checking these dependencies one by one?

A large scale project could have a vast amount of transitive dependencies... And monitoring them all for security patch would be borderline impossible...

Thank you.

[Tratcher]

Well, thank you but you are kind of stating the obvious 😅

Just making sure it got said 😁.

Yeah, in 2.1 this is hard to keep track of. I don't have direct answer, but I'll check if anyone else does.

We've got this working better in 3.1 where we ship an updated version of every package, even if it wasn't directly affected by a patch.

[Indigo744]

Yeah, in 2.1 this is hard to keep track of. I don't have direct answer, but I'll check if anyone else does.

We've got this working better in 3.1 where we ship an updated version of every package, even if it wasn't directly affected by a patch.

Thank you for your response. I'm curious what you'll be able to find. 😄
FYI we can't upgrade to 3.1 due to the fact we still need to target the .Net Framework...

In any case, I think I will pull all transitive dependencies from the Microsoft.AspNetCore.* package and add them as direct reference. A quick look around tells me that it should amount to 20-ish dependencies, so it's not the end of the world...

[Pilchie]

There isn't really a better way. One thing we have talked about is trying to rev the meta packages, but that isn't easy to do either.

[Indigo744]

One thing we have talked about is trying to rev the meta packages, but that isn't easy to do either.

You mean releasing a new version of a parent package depending of it? Like, for instance, Microsoft.AspNetCore.Server.IISIntegration orMicrosoft.AspNetCore.Authentication?

That would be great, but I suppose this is not as easy as it seems?

[Tratcher]

No, the metapackages are Microsoft.AspNetCore.All, and Microsoft.AspNetCore.App.

[Pilchie]

But, we'd have to either flow the version bump through any transitive packages, or we'd have to lift all the patched packages explicitly in the meta-package.

[Indigo744]

No, the metapackages are Microsoft.AspNetCore.All, and Microsoft.AspNetCore.App.

Oh I see, sorry for the confusion 🤦‍♂️

But, we'd have to either flow the version bump through any transitive packages, or we'd have to lift all the patched packages explicitly in the meta-package.

I can understand why this would be a huge undertaking, especially if it's a widely used package.

However, I can't help but think this is a blind spot in the way security patch are distributed.

Nuget is partly to blame here, as the choice of "always take the lowest possible version" may be good for stability, but actively works against security best practice (you know, the "keep your system and dependencies up to date" mantra). I don't know if I should even bring this up in their repository, since it seems clear it was made to work this way.
Apparently, I'm not the only one bitten by this issue: NuGet/Home#5553

For now, I'll stick with monitoring this space for advisories and bumping package version manually 😩

If anyone is interested, here is what I added to my csproj in order to get the patch in the advisory while avoid the package manager to offer the upgrade to 2.2:

<PackageReference Include="Microsoft.AspNetCore.Http" Version="[2.1.22,2.2)" />

[Indigo744]

The package manager in Visual Studio 2017 allows the Version="[2.1.22,2.2)" syntax but offers upgrades to later versions anyway. 😢 Has that been improved in Visual Studio 2019?

Yes, it works in VS 2019 and doesn't offer the upgrade.

However, there is a catch (it would be too simple, you know!).

If, say, a new version 2.1.23 is released, and I click on the big and nice "Update" button in the package manager, it will install the 2.1.23 while completely overwriting the constraints, leading to:

<PackageReference Include="Microsoft.AspNetCore.Http" Version="2.1.23" />

So... We update manually by editing the csproj. 😪

[Pilchie]

Can we leave discussions of the NuGet package manager behavior over on NuGet/Home instead of here.

[Indigo744]

Can we leave discussions of the NuGet package manager behavior over on NuGet/Home instead of here.

Of course, sorry.

Thank you for your feedbacks 👍

[ghost]

Thank you for contacting us. Due to a lack of activity on this discussion issue we're closing it in an effort to keep our backlog clean. If you believe there is a concern related to the ASP.NET Core framework, which hasn't been addressed yet, please file a new issue.

This issue will be locked after 30 more days of inactivity. If you still wish to discuss this subject after then, please create a new issue!