Microsoft Security Advisory ASPNETCore-July18: ASP.NET Core Denial Of Service Vulnerability

[blowdart]

Microsoft Security Advisory ASPNETCore-July18: ASP.NET Core Denial Of Service Vulnerability

Executive summary

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

Microsoft is aware of a denial of service vulnerability in ASP.NET Core when a malformed request is terminated. An attacker who successfully exploited this vulnerability could cause a denial of service attack.

The update addresses the vulnerability by correcting how ASP.NET Core handles such requests.

Announcement

The original announcement for this issue can be found at aspnet/Announcements#311

Mitigation factors

• If your application is behind a forwarding proxy such is Internet Information Server, Azure Application Gateway or nginx you will not be affected.

Mitigation factors

• If your application is behind a forwarding proxy such is Internet Information Server, Azure Application Gateway or nginx you will not be affected.

Affected software

Any ASP.NET Core based application that uses Microsoft.AspNetCore.Server.Kestrel.Core with a vulnerable version listed below and not hosted behind a forwarding proxy.

Package name	Vulnerable versions	Secure versions
Microsoft.AspNetCore.Server.Kestrel.Core	2.0.0, 2.0.1, 2.0.2, 2.0.3 2.1.0, 2.1.1	2.0.4 2.1.2
Microsoft.AspNetCore.All	2.0.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6, 2.0.7, 2.0.8 2.1.0, 2.1.1	2.0.9 2.1.2
Microsoft.AspNetCore.App	2.1.0, 2.1.1	2.1.2

Advisory FAQ

How do I know if I am affected?

.NET Core has two types of dependencies: direct and transitive. Direct dependencies are dependencies where you specifically add a package to your project, transitive dependencies occur when you add a package to your project that in turn relies on another package.

For example, the Microsoft.AspNetCore.Mvc package depends on the Microsoft.AspNetCore.Mvc.Core package. When you add a dependency on Microsoft.AspNetCore.Mvc in your project, you're taking a transitive dependency on Microsoft.AspNetCore.Mvc.Core.

Any application that has a direct or transitive dependency on the affected package can be exposed to the vulnerability if it does not meet any of the mitigation factors.

How do I fix the issue?

ASP.NET Core 2.1

To update ASP.NET Core 2.1 you should download and install the .NET Core SDK 2.1.302 on your development machines and build servers, and the .NET Core Runtime 2.1.2 on your deployment servers. Your application will roll forward to these versions on an application restart.

ASP.NET Core 2.0

If you're targeting ASP.NET Core 2.0 and using the Microsoft.AspNetCore.All metapackage update its version number to 2.0.9 to update the Microsoft.AspNetCore.Server.Kestrel.Core package, recompile, and redeploy. On your deployment servers, you should download and install the .NET Core 2.0.9 using the Windows Server Hosting Bundle for Windows and the dotnet-hosting-2.0.9 package for Linux servers.

ASP.NET 2.0 & 2.1 not targeting the meta-packages

.NET Core projects have two types of dependencies: direct and transitive. You must update your projects using the following instructions to address both types of dependency.

Direct dependencies

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

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 which, 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 three ways, depending on your project format:

• In the Visual Studio Solution Explorer window, which supports searching.
• By examining the project.assets.json file contained in the obj directory of your project for csproj based projects.

The project.assets.jsonfiles are the authoritative list of all packages used by your project, containing both direct and transitive dependencies.

Fixing direct dependencies in Visual Studio 2017

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.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.8" />
  </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 Microsoft.AspNetCore.All version 2.0.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 Microsoft.AspNetCore.All 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.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.9" />
  </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.

Discovering and fixing transitive dependencies

There are two ways to view transitive dependencies. You can either use Visual Studio’s Solution Explorer, or you can review the project.assets.json file .

Using Visual Studio Solution Explorer

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.

Manually reviewing project.assets.json

Open the project.assets.json file from your project’s 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:

• Examine the line on which they are found, the version number is after the /.
• Compare to the vulnerable versions table.

For example, a search result that shows Microsoft.AspNetCore.Server.Kestrel.Core/2.0.0 is a reference to version 2.0.0 of Microsoft.AspNetCore.Server.Kestrel.Core.
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

• None of your direct dependencies depend on any vulnerable packages, or
• You have already fixed the problem by updating the direct dependencies.

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 Microsoft.AspNetCore.Server.Kestrel.Core 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.Server.Kestrel.Core" Version="2.0.34 />
    <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.

Rebuilding your application

Finally you must rebuild your application, test, and redeploy.

Other Information

Reporting Security Issues

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.

Support

You can ask questions about this issue on GitHub in the .NET Core or ASP.NET Core organizations. These are located at https://github.com/dotnet/ and https://github.com/aspnet/. The Announcements repo for each product (https://github.com/dotnet/Announcements and https://github.com/aspnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the 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.

Revisions

V1.1 (July 10, 2018): Added .App meta-package details.
V1.0 (July 10, 2018): Advisory published.

Version 1.0

Last Updated 2018-07-10

[VictorioBerra]

We are being directed to:

To update ASP.NET Core 2.1 you should download and install the .NET Core SDK 2.1.302 on your development machines and build servers, and the .NET Core Runtime 2.1.2 on your deployment servers.

Yet https://www.microsoft.com/net/download/all does not show a download or bundle for .NET Core SDK 2.1.302.

[natemcmaster]

We're waiting for the marketing page to propagate changes. In the meantime, use https://github.com/dotnet/core/blob/master/release-notes/download-archives/2.1.2-download.md.

[blowdart]

The downloads page is now updated.

[johnkors]

The recommended fix Microsoft.AspNetCore.All/2.0.9 has the following dependency chain via Redis packages to System.Net.Security/4.3.0.

=> Microsoft.Extensions.Caching.Redis/2.0.2
=> StackExchange.Redis.StrongName/1.2.4
=> System.Net.Security/4.3.0

System.Net.Security/4.3.0 was reported earlier as having a vulnerability in https://github.com/dotnet/corefx/issues/19535

[johnkors]

The same applies to Microsoft.AspNetCore.All/2.1.2.

[johnkors]

Would that mean that we in addition to these fixes need to install a direct reference to System.Net.Security v.4.3.1 or higher?

[johnkors]

Could you clarify here, @blowdart ..? The recommended fix is in conflict with another vulnerability, as I see it..?

[blowdart]

You'd normally address this with a direct dependency, until the Stack Exchange package is updated. But because this is a framework package the runtime will pick up the updated one anyway, because it's part of the runtime.

[johnkors]

Not sure I follow. When I look at a project.assets.json generated from referring the recommended fixes here, I get an entry showing use of a vulnerable version of system.net.security. How is an updated version other than the one refererred to in the assets file being used here?

[johnkors]

Sorry to bother, @blowdart , but this was a bit confusing. How does the runtime pick up another package than the System.Net.Security/4.3.0 defined in the project.assets.json as a transient?

[johnkors]

perhaps @natemcmaster can elaborate..?

[natemcmaster]

System.Net.Security/4.3.0 is ignored by the SDK altogether in .NET Core and .NET Standard 2.0 and up projects. This was the result of condensing hundreds of System.* packages into one for the 2.0 release. The runtime gets System.Net.Security.dll from the shared framework, not from NuGet packages.

For a complete list of packages which were condensed in the 2.0 release, see here: https://github.com/dotnet/sdk/blob/ab2176b3447e3e7820b5a340408110b6d498f907/src/Tasks/Common/targets/Microsoft.NET.DefaultPackageConflictOverrides.targets#L81

[johnkors]

Ah, thanks for clarifying! Very helpful. Will the fact that a package will be overridden be reflected in the generated projects.assets.json file at all..?

Or is that targets file the only place to where one can get that info..?

Background: I'm asking because dotnet-retire is currently flagging System.Net.Security/4.3.0 as a vulnerability, but based on what you explained here it would be a false positive.

[natemcmaster]

Will the fact that a package will be overridden be reflected in the generated projects.assets.json file at all..?

No. This package will continue to be in the restore graph as long as packages continue to target .NETStandard 1.x. I highly encourage all library authors to consider moving to .NET Standard 2.0 for this reason and others like it.

[aspnet-hello]

We periodically close 'discussion' issues that have not been updated in a long period of time.

We apologize if this causes any inconvenience. We ask that if you are still encountering an issue, please log a new issue with updated information and we will investigate.