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.
Microsoft is aware of a remote code execution vulnerability exists in ASP.NET Core software when the software fails to handle objects in memory. An attacker who successfully exploited the vulnerability could run arbitrary code in the context of the current user.
A remote unauthenticated attacker could exploit this vulnerability by issuing specially crafted requests to the ASP.NET Core application.
The update addresses the vulnerability by correcting how the ASP.NET Core web application handles objects in memory.
The original announcement for this issue can be found at https://github.com/aspnet/Announcements/issues/403
Microsoft has not identified any mitigating factors for this vulnerability.
If you have a runtime or SDK with a version listed in affected software or your application has a dependency on any of the packages listed in affected packages, you are exposed to the vulnerability.
Any .NET Core 2.1, 3.0 or 3.1 application using SignalR.
Any ASP.NET Core-based application that uses any of the vulnerable packages shown below, or any ASP.NET Core application running on .NET Core 2.1.x, 3.0.0, 3.0.1 or 3.1.0.
Package name | Vulnerable versions | Secure versions
------------ | ------------------- | -------------------------
Microsoft.AspNetCore.Http.Connections | 1.0.0 - 1.0.4 | 1.0.15
Microsoft.AspNetCore.App | 2.1.0 - 2.1.14
3.0.0
3.1.0 | 2.1.15
3.0.1
3.1.1
Microsoft.AspNetCore.All | 2.1.0 - 2.1.14 | 2.1.15
First examine the versions of .NET Core you have installed. 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:
2.1.802 [C:\Program Files\dotnet\sdk]
3.0.101 [C:\Program Files\dotnet\sdk]
3.1.100 [C:\Program Files\dotnet\sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.14 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.14 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.0.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.14 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.0.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.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
If you have multiple runtimes or SDKs installed, you must update all runtimes or SDKs separately.
Once you've installed the updated runtime or SDK, restart your apps for the update to take effect.
Update your runtime and SDKs to the versions listed in Updated runtimes and SDKs then restart your application.
First update your .NET Core runtimes and SDKs to the versions listed in Updated runtimes and SDKs. As targeting .NET Framework adds dependencies for various packages you must update the dependencies your application uses, recompile and redeploy your application.
Direct dependencies are discoverable by examining your csproj
file. They can be fixed by editing the project file or using NuGet to update the dependency.
Transitive dependencies occur when you add a package to your project that in turn relies on another package. For example, if Contoso publishes a package Contoso.Utility
that, in turn, depends on Contoso.Internals
and you add the Contoso.Utility
package to your project now your project has a direct dependency on Contoso.Utility
and, because Contoso.Utility
depends 'Contoso.Internals', your application gains a transitive dependency on the Contoso.Internals
package.
Transitive dependencies are reviewable in two ways:
project.assets.json
file contained in the obj directory of your project for csproj
based projectsThe project.assets.json
files are the authoritative list of all packages used by your project, containing both direct and transitive dependencies.
There are two ways to view transitive dependencies. You can either use Visual Studio鈥檚 Solution Explorer, or you can review the project.assets.json
file).
To use Solution Explorer, open the project in Visual Studio, and then press Ctrl+; to activate the search in Solution Explorer. Search for the vulnerable package and make a note of the version numbers of any results you find.
For example, searching for Microsoft.AspNetCore.Mvc.Core
in an example project that contains a package that takes a dependency on Microsoft.AspNetCore.Mvc
shows the following results in Visual Studio 2017:
The search results appear as a tree. In the previous results, you can see that a reference to Microsoft.AspNetCore.Mvc.Core
version 1.1.2 is discovered.
Under the Dependencies node is a NuGet node. Under the NuGet node is the list of packages you have directly taken a dependency on and their versions.
In screenshot, the application takes a direct dependency on Microsoft.AspNetCore.Mvc
. Microsoft.AspNetCore.Mvc
in turn has leaf nodes that list its dependencies and their versions.
The Microsoft.AspNetCore.Mvc
package takes a dependency on a version of Microsoft.AspNetCore.Mvc.ApiExplorer
, that in turn takes a dependency on a version of Microsoft.AspNetCore.Mvc.Core
.
Open the project.assets.json file from your project鈥檚 obj directory in your editor. We suggest you use an editor that understands JSON and allows you to collapse and expand nodes to review this file.
Visual Studio and Visual Studio Code provide JSON-friendly editing.
Search the project.assets.json file for the vulnerable package, using the format packagename/
for each of the package names from the preceding table. If you find the assembly name in your search:
v
/
.For example, a search result that shows System.IO.Pipelines/4.5.0
is a reference to version 4.5.0 of System.IO.Pipelines
.
If your project.assets.json file includes references to the vulnerable package, then you need to fix the transitive dependencies.
If you have not found any reference to any vulnerable packages, this means either
Open projectname.csproj in your editor. If you're using Visual Studio, right-click the project and choose Edit projectname.csproj from the context menu, where projectname is the name of your project. Look for PackageReference
elements. The following shows an example project file:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.1</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.Http.Connections" Version="1.0.0" />
</ItemGroup>
</Project>
The preceding example has a reference to the vulnerable package, as seen by the single PackageReference
element. The name of the package is in the Include
attribute.
The package version number is in the Version
attribute. The previous example shows a single direct dependency on System.IO.Pipelines
version 4.5.0
To update the version to the secure package, change the version number to the updated package version as listed on the table previously.
In this example, update System.IO.Pipelines
to the appropriate fixed package number for your major version. Save the csproj file. The example csproj now looks as follows:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.1</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.Http.Connections " Version="1.0.15" />
</ItemGroup>
</Project>
If you're using Visual Studio and you save your updated csproj file, Visual Studio will restore the new package version.
You can see the restore results by opening the Output window (Ctrl+Alt+O) and changing the Show output from drop-down list to Package Manager.
If you're not using Visual Studio, open a command line and change to your project directory. Execute the dotnet restore
command to restore the updated dependencies.
Now recompile your application. If after recompilation you see a Dependency conflict warning, you must update your other direct dependencies to versions that take a dependency on the updated package.
If your transitive dependency review found references to the vulnerable package, you must add a direct dependency to the updated package to your csproj file to override the transitive dependency.
Open projectname.csproj in your editor. If you're using Visual Studio, right-click the project and choose Edit projectname.csproj from the context menu, where projectname is the name of your project.
Look for PackageReference
nodes, for example:
<Project Sdk="Microsoft.NET.Sdk.">
<PropertyGroup>
<TargetFramework>net461</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="ThirdParty.NotUpdatedYet" Version="2.0.0" />
</ItemGroup>
</Project>
You must add a direct dependency to the updated version of the vulnerable package by adding it to the csproj file.
You do this by adding a new line to the dependencies section, referencing the fixed version.
For example, if your search showed a transitive reference to a vulnerable System.ServiceModel.Http
version, you'd add a reference to the fixed package number.
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>net461</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.Http.Connections" Version="1.0.15" />
<PackageReference Include="ThirdParty.NotUpdatedYet" Version="2.0.0" />
</ItemGroup>
</Project>
After you've added the direct dependency reference, save your csproj file.
If you're using Visual Studio, save your updated csproj file and Visual Studio will restore the new package versions.
You can see the restore results by opening the Output window (Ctrl+Alt+O) and changing the Show output from drop-down list to Package Manager.
If you're not using Visual Studio, open a command line and change to your project directory. Execute the dotnet restore
command to restore the new dependencies.
Finally, you must rebuild your application, test, and redeploy.
If you have found a potential security issue in .NET Core, please email details to [email protected]. 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.
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.
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.
Brennan Conroy of Microsoft Corporation
V1.1 (February 4, 2020): Fix up runtime version number.
V1.0 (January 14, 2020): Advisory published.
_Version 1.1_
_Last Updated 2020-02-04_
@blowdart something I didn't see covered in the announcement but I think might be a benefit to know --
Will those of us pulling containers from the :3.1
tag for docker containers -- e.g. mcr.microsoft.com/dotnet/core/aspnet:3.1-alpine
-- automatically the runtime/sdk update the next time the containers are built?
It seems that this would be the case, as I imagine Runtime 3.1.1 or SDK 3.1.101 would be matched to the 3.1
tags here, but I couldn't confirm that at first glance and wanted to ask. I know this doesn't affect the packages one is using but wanted to confirm for the runtime/sdk at least.
EDIT: Nevermind, I had missed it in the tags list:
The containers get updated along with everything else, it's just they lag a bit.
@blowdart So 2.2 is not affected by this and the other today's advisory? Seems odd that versions earlier and later are affected, but this one isn't. Or is it not listed, because 2.2 is not supported anymore anyway?
2.2 is out of support and so will not be listed, regardless of whether it is affected or not.
Will Azure app service be getting updates soon or should we be thinking of a self contained deployment? (Same question applies to 18336.)
Clarification please; This announcement states
A remote unauthenticated attacker could exploit this vulnerability by issuing specially crafted requests to the ASP.NET Core application.
The linked CVE states
Exploitation of the vulnerability requires that a user open a specially crafted file with an affected version of ASP.NET Core. In an email attack scenario, an attacker could exploit the vulnerability by sending the specially crafted file to the user and convincing the user to open the file.
The implication of the two are obviously very different :)
Yea, the CVE wording is standardised. You can't send emails to asp.net, but if you were to use the vulnerable parsing code from an uploaded file you'd be vulnerable.
Can you confirm that only front-end web servers are directly subjet to attacks based on this vulerability? (I.e. the attacker would have to be able to directly send requests to an ASP.NET Core app)
Bonus question: as a proud Azure customer, I'd hope that Application Gateway WAF is able to mitigate this kind of attack. Do you actively work with these guys?
I can't confirm that. If you had an n-tier architecture and used signal-r between the tiers it may be vulnerable.
We don't work with WAF (heck they block identity cookies sometimes) but this wouldn't be something WAF would easily parse and block anyway.
For machines running .NET Core 2.1, you should download and install Runtime 2.1.511 or SDK 2.1.511 (Visual Studio 2017) or SDK 2.1.608 (Visual Studio 2019) from
@blowdart Are those runtime and SDK version numbers for .NET Core 2.1 correct?
The linked page shows versions:
(Also applies to #18336)
I have a hard time reconciling the following statements from the announcement:
Any ASP.NET Core-based application that uses any of the vulnerable packages shown below, or any ASP.NET Core application running on .NET Core 2.1.x, 3.0.0, 3.0.1 or 3.1.0.
which seems to imply that an application that does not use Signal-R is affected. Yet in the _Affected software_ section it says:
Any .NET Core 2.1, 3.0 or 3.1 application using Signal-R.
@blowdart's comment about 'signal-r between the tiers' also seems to imply this is a problem in Signal-R.
Is a .NET Core 2.1 or 3.1 application that does not use Signal-R affected by this vulnerability?
Agreed with @etortec , the wording needs to be clarified if this is limited to apps using SignalR.
Generally we write these things to cover all available cases. For the default asp.net setup it's limited to SignalR, however in your own app you might end up calling the code that was fixed.
What this boils down to is, as always, _patch_.
@blowdart - I've checked some of our Azure app services again this morning and I can see they still haven't been updated, do you know if there's a timeline for this or should I ask this somewhere else? Thanks
That is a question for Azure support I'm afraid.
Last I heard was that the rollout was starting yesterday, and expected to be in all regions by the end of January. It's actually in the .NET Core release notes now:
https://github.com/dotnet/core/blob/master/release-notes/3.1/3.1.1/3.1.1.md#azure-app-services
Thanks both
@blowdart Can you clarify applicability to Azure Functions please. The advisory stated:
any ASP.NET Core application running on .NET Core ...
any .NET Core ... application using Signal-R.
which I understand to mean, if your .NET Core application is hosted by ASP.NET Core or using SignalR then it's vulnerable.
If that's the case, then a .NET Core functionapp won't be vulnerable unless it's also using SignalR binding.
Have I parsed that correctly? Ta.
@petevb Pretty much yes.
We import ASP.NET Core via implicit reference. I can't figure out how to get the update to apply:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp3.0</TargetFramework>
<RuntimeFrameworkVersion>3.0.0</RuntimeFrameworkVersion>
<LangVersion>8.0</LangVersion>
<PreserveCompilationContext>true</PreserveCompilationContext>
<OutputType>Exe</OutputType>
<UserSecretsId>redacted</UserSecretsId>
<AssetTargetFallback>$(AssetTargetFallback);dotnet5.6;portable-net45+win8</AssetTargetFallback>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
<TypeScriptToolsVersion>3.7</TypeScriptToolsVersion>
<TypeScriptCompileBlocked>True</TypeScriptCompileBlocked>
<NoWarn>8032</NoWarn>
</PropertyGroup>
<ItemGroup>
<!-- non-MS snipped -->
<PackageReference Include="System.Net.Http" Version="4.3.3" />
<PackageReference Include="System.Text.Encoding.CodePages" Version="4.5.0" />
<PackageReference Include="Microsoft.AspNetCore.Mvc.NewtonsoftJson" Version="3.0.0" />
</ItemGroup>
I installed the new .SDK but visual studio tells me I'm still referencing Microsoft.AspNetCore.App version 3.0.1 and deps.json
contains "Microsoft.AspNetCore.Http.Connections.Common": "3.0.0.0",
EDIT: Solved. Bad caching.
Small typo both here in the discussion thread and in the announcment, @blowdart :
Updated runtimes and SDKs
For machines running .NET Core 2.1, you should download and install Runtime 2.1.511 or SDK 2.1.511 (Visual Studio 2017) or SDK 2.1.608 (Visual Studio 2019) from ..
I assume this is meant to be Runtime 2.1.15, and not ~2.1.511~ (as it does not exist 馃 )
Yup :)
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!
Most helpful comment
I have a hard time reconciling the following statements from the announcement:
which seems to imply that an application that does not use Signal-R is affected. Yet in the _Affected software_ section it says:
@blowdart's comment about 'signal-r between the tiers' also seems to imply this is a problem in Signal-R.
Is a .NET Core 2.1 or 3.1 application that does not use Signal-R affected by this vulnerability?