[Discussion] Microsoft Security Advisory CVE-2017-11879: Open Redirect can cause Elevation Of Privilege

[blowdart]

Microsoft Security Advisory CVE-2017-11879: Open Redirect can cause Elevation Of Privilege

Executive Summary

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

Microsoft is aware of a security vulnerability some public versions of ASP.NET Core where an Open Redirect exists, leading to Elevation Of Privilege.

Discussion

Please use https://github.com/aspnet/Mvc/issues/7053 for discussion of this advisory.

Mitigation Factors

ASP.NET Core applications using version 1.0.x or 1.1.x are not affected.

Affected Software

The vulnerabilities affect any Microsoft .NET Core project if it uses the following affected package versions.

Package name	Package versions	Fixed package versions
Microsoft.AspNetCore.All	2.0.0	2.0.3
Microsoft.AspNetCore.Mvc.Core	2.0.0	2.0.1

Advisory FAQ

How do I know if I am affected?

.NET Core and ASP.NET Core have two types of dependencies: direct and transitive. If your project has a direct or transitive dependency on any of the packages and versions listed above, you are affected.

Direct Dependencies

Direct dependencies are dependencies where you specifically add a package to your project. For example, if you add the Microsoft.AspNetCore.Mvc package to your project then you have taken a direct dependency onMicrosoft.AspNetCore.Mvc.

Direct dependencies are discoverable by reviewing your csproj file.

Transitive Dependencies

Transitive dependencies occur when you add a package to your project that in turn relies on another package. For example, if you add the Microsoft.AspNetCore.Mvc package to your project it depends on the Microsoft.AspNetCore.Mvc.Core package (among others). Your project has a direct dependency on Microsoft.AspNetCore.Mvc and a transitive dependency on the Microsoft.AspNetCore.Mvc.Core package. Transitive dependencies are reviewable in the Visual Studio Solution Explorer window, which supports searching, or by reviewing the project.lock.json file contained in the root directory of your project for project.json projects or the project.assets.json file contained in the obj directory of your project for csproj projects. These files are the authoritative list of all packages used by your project, containing both direct and transitive dependencies.

How do I fix my affected application?

You will need to fix both direct dependencies and review and fix any transitive dependencies. The affected packages and versions in the previous “Affected Software” section include each vulnerable package, the vulnerable versions, and the patched versions

---

If you are targeting .NET Core a "meta-package" is used, Microsoft.AspNetCore.All. You should begin by updating its version number to 2.0.3, this will pull in the fixed Microsoft.AspNetCore.Mvc.Core package.

If you are targeting .NET Framework you should first update the Microsoft.AspNetCore version to the version number to 2.0.1, then adjust the version number for any other packages beginning with Microsoft.AspNetCore. to 2.0.3.

---

Fixing Direct Dependencies – Projects targeting .NET Core

Open your projectname.csproj file in your editor, or right click the project in Visual Studio 2017 and choose Edit projectname.csproj from the content menu, where projectname is the name of your project. Look for PackageReference nodes. 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.0" />
  </ItemGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.0" />
  </ItemGroup>
</Project>

The example has has a reference to the vulnerable metapackage, as seen by the single PackageReference elements. The name of the package is in the Include attribute, and the package version number is in the Version attribute that is exposed to the right of the package name. The example shows a single direct dependency on Microsoft.AspNetCore.All version 2.0.0.

To update to the fixed package, change the version number to the updated package version. In the example, this would be updating Microsoft.AspNetCore.All to 2.0.3.

After updating the vulnerable package version, save your csproj file. The example csproj would now look as follows:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.3" />
  </ItemGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.0" />
  </ItemGroup>
</Project>

If you are using Visual Studio and 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 are not using Visual Studio open a command line and change to your project directory. Execute the dotnet restore command to restore your new dependency.

Fixing Direct Dependencies – Projects targeting .NET Framework

Open your projectname.csproj file in your editor, or right click the project in Visual Studio 2017 and choose Edit projectname.csproj from the content menu, where projectname is the name of your project. Look for PackageReference nodes. The following shows an example project file:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net461</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Mvc.Core" Version="2.0.0" />
  </ItemGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.0" />
  </ItemGroup>
</Project>

The example has has a reference a single packages, as seen by the PackageReference element. The name of the package is in the Include attribute, and the package version number is in the Version attribute that is exposed to the right of the package name. The example shows a direct dependency on one of the vulnerable packages from the table above, Microsoft.AspNetCore.Core version 2.0.0.

To update to the fixed package, change the version number to the updated package version. In the example, this would be updating Microsoft.AspNetCore.Core to 2.0.1.

After updating the vulnerable package version, save your csproj file. The example csproj would now look as follows:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net461</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Mvc.Core" Version="2.0.1" />
  </ItemGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.0" />
  </ItemGroup>
</Project>

If you are using Visual Studio and 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 are not using Visual Studio open a command line and change to your project directory. Execute the dotnet restore command to restore your new dependency.

After updating your direct dependencies

Recompile your application.

If after recompilation you see a Dependency conflict warning, you must update your other direct dependencies to the appropriate version.

For example if your project refers a direct reference to Microsoft.AspNetCore.Mvc.Cors with a version number of 2.0.0 when you update your Microsoft.AspNetCore.Mvc package to 2.0.1, compilation will throw:

NU1012 Dependency conflict. Microsoft.AspNetCore.Mvc 2.0.1 expected Microsoft.AspNetCore.Mvc.Cors >= 2.0.1 but received 2.0.0

To fix this, edit the version for the expected package to be the version expected by updating your project.json in the same way that you used to update the vulnerable package versions.

After you have addressed all of your direct dependencies, you must also review your transitive dependencies.

Reviewing Transitive Dependencies

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

Using Visual Studio Solution Explorer (VS2017)

If you want to use Solution Explorer, open your project in Visual Studio 2017, and then press Ctrl+; to activate the search in Solution Explorer. Search for each of the vulnerable package names 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 these results, you can see we have found references to Microsoft.AspNetCore.Mvc.Core version 1.1.2.

Under the Dependencies node will be a NuGet node. Under the NuGet node will be the list of packages you have directly taken a dependency on and their versions. In this example, 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. In the example the Microsoft.AspNetCore.Mvc package takes a dependency on a version of Microsoft.AspNetCore.Mvc.ApiExplorer which in turn takes a dependency on a vulnerable version of Microsoft.AspNetCore.Mvc.Core.

Manually reviewing project.assets.json (VS2017)

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; both Visual Studio and Visual Studio Code provide this functionality.

Search the project.assets.json file for each of the vulnerable packages, using the format packagename/ for each of the package names from the table above. If you find the assembly name in your search examine the line on which they are found, the version number is after the / and compare to the vulnerable versions table above. For example a search result that shows Microsoft.AspNetCore.Mvc.Cors/1.1.0 is a reference to v1.1.0 of Microsoft.AspNetCore.Mvc.Cors. If your project.assets.json file includes references to any of the vulnerable packages shown above then you will need to fix the transitive dependencies.

If you have not found any reference to any vulnerable packages this means 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 any of the vulnerable packages you must add a direct dependency to the updated package to your csproj file to override the transitive dependency. Open your projectname.csproj file in your editor, or right click on the project in Visual Studio 2017 and choose Edit projectname.csproj from the content menu, where projectname is the name of your project. Look for PackageReference nodes, for example:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net461</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="ThirdParty.NotUpdatedYet" Version="2.0.0" />
  </ItemGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.0" />
  </ItemGroup>
</Project>

For each of the vulnerable packages your search returned you must add a direct dependency to the updated version by adding it to the csproj file. You do this by adding a new line to the dependencies section, referring the fixed version. For example, if your search showed a transitive reference to the vulnerable Microsoft.AspNetCore.Mvc.Core version 2.0.0 you would add a reference to the fixed version, 2.0.1.

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net461</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Mvc.Core" Version="2.0.1" />
    <PackageReference Include="ThirdParty.NotUpdatedYet" Version="2.0.0" />
  </ItemGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.0" />
  </ItemGroup>
</Project>

After you have added the direct dependency reference, save your csproj file.

If you are 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 are not using Visual Studio, open a command line and change to your project directory. Execute the dotnet restore command to restore your new dependencies.

Rebuilding your application

Finally rebuild your application, test as you would do normally and redeploy using your favored deployment mechanism.

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 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 where you can ask questions.

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.

Acknowledgments

Thanks to Kévin Chalet for reporting this issue.

External Links

CVE-2017-11879:

Revisions

V1.0 (Nov 14, 2017): Advisory published. V1.1 (Nov 14, 2017): Fixed metapackage version. V1,2 (Nov 14, 2017): Fixed metapackage version in samples.

Version 1.2 Last Updated 2017-11-14

[Daniel15]

Any more information? Is every application vulnerable, or only applications that use redirects in a particular way?

[tillig]

In attempting to update Microsoft.AspNetCore.Mvc.Core to 2.0.1 the update fails on attempting to resolve Microsoft.Extensions.DependencyModel 2.0.3. That version does not exist in NuGet.

[kevinchalet]

Is every application vulnerable, or only applications that use redirects in a particular way?

Every application that uses ControllerBase.LocalRedirect() or returns a LocalRedirectResult is impacted. If you've kept the AccountController class coming with the ASP.NET Core template for VS, you're likely vulnerable as LocalRedirect is used to redirect the users back to the original return URL when they log in or register.

[pranavkm]

@tillig thanks for bringing the missing packages to our attention. They just got uploaded to NuGet.org (https://www.nuget.org/packages/Microsoft.Extensions.DependencyModel) and you should be able to restore it as soon as NuGet.org's index is updated.

[scottsauber]

@blowdart - There doesn't appear to be a 2.0.1 of the Microsoft.AspNetCore.All metapackage, only 2.0.3.

[blowdart]

@Eilon @muratg - I don't control the publishing or metapackages.

[blowdart]

Ah. Apparently I was given the wrong metapackage version for the bulletin. This is now corrected. 2.0.3 it is.

[scottsauber]

The dot.net site doesn't have the latest Windows Server Hosting installer with these fixes.

When I upgrade to .All v2.0.3, the server bombs bc the Runtime Store doesn't have the latest dll. I'm not sure who owns the downloads for that site? Any Microsoft employee who could contact that person and let them know would be great.

The error I got is below: An assembly specified in the application dependencies manifest (ProjectName.AspNetCore.deps.json) was not found: package: 'Microsoft.AspNetCore.Antiforgery', version: '2.0.1' path: 'lib/netstandard2.0/Microsoft.AspNetCore.Antiforgery.dll' This assembly was expected to be in the local runtime store as the application was published using the following target manifest files: aspnetcore-store-2.0.3.xml

[blowdart]

@muratg @shirhatti Any news on when the hosting installer gets updated?

[muratg]

Adding @leecow @joeloff re @blowdart's last question.

[leecow]

Working on the dotnet site now. In the meantime, you can grab it directly from https://download.microsoft.com/download/5/C/1/5C190037-632B-443D-842D-39085F02E1E8/DotNetCore.2.0.3-WindowsHosting.exe

[scottsauber]

That worked - thanks @leecow! It hadn't really hit me that this is a downside with the Runtime Store/.All package until this first upgrade, that the package in your project and the server installer need to be in lockstep. I guess I should be using Docker.

It would be cool to have a self-updating command within the dotnet cli.

[guardrex]

@leecow When we have the new hosting bundle installer link, I'll get it into the docs asap.

btw- @blowdart I just came over from the Announcement topic. In the section Fixing Direct Dependencies – Projects targeting .NET Core it still shows that the go-to metapackage for "All" is 2.0.1. It should be 2.0.3, correct? I saw you say you updated :point_up:, but it looks like that section needs the version fix, too ...

To update to the fixed package, change the version number to the updated package version. In the example, this would be updating Microsoft.AspNetCore.All to 2.0.1.

[blowdart]

@guardrex Fixed, thanks

[leecow]

@guardrex - links on https://github.com/dotnet/core/blob/master/release-notes/download-archives/2.0.3.md are correct. Only the posting to dot.net are pending.

[guardrex]

@leecow We use this one :point_right: https://aka.ms/dotnetcore.2.0.0-windowshosting ... so I presume you'll have me take that to ...

https://aka.ms/dotnetcore.2.0.3-windowshosting

... when the time comes. Is that right?

[leecow]

I hadn't planned on creating an aka.ms url but suppose I could if it's needed.

[guardrex]

We've gone back-and-forth with aka.ms links for the hosting bundle. @Rick-Anderson, do we especially need an aka.ms link for the hosting bundle installer for the topics? [EDIT] ... can we use :point_right: https://download.microsoft.com/download/5/C/1/5C190037-632B-443D-842D-39085F02E1E8/DotNetCore.2.0.3-WindowsHosting.exe

[Rick-Anderson]

@guardrex If you don't use a fwlink you'll have to update the doc when the latest download link changes. Your call

[guardrex]

@leecow standby a sec ... let me talk to Rick offline for a sec about it.

[leecow]

Created the following which we'll keep updated and get you out of the link update game.

• https://aka.ms/dotnetcore-2-windowshosting
• https://aka.ms/dotnetcore-1-windowshosting

[guardrex]

@leecow Ah ... thank u sir! :smile:

[mikes-gh]

Using openvas for pen testing I still get a warning as the vunerable packages is installed even with hosting bundle 2.0.8 Is this for backward compatibility? This is after removing everything and reinstalling. openvas checks for the existance of the package not whether its being used. Presumably if its there it could inadvertantly be used.

Vulnerability Detection Result
Installed version: 2.0.0.17205
File checked:      c:\program files (x86)\dotnet\store\x86
etcoreapp2.0\microsoft.aspnetcore.mvc.core\2.0.0\lib
etstandard2.0\Microsoft.AspNetCore.Mvc.Core.dll
Fixed version:     2.0.1

[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.