How do I know if I am affected? ASP.NET Core has two different types of dependencies: direct and transitive. If your project has either a direct or transitive dependency on any of the affected packages listed in the “Affected Software” section, then it may be affected.

Direct Dependencies
Direct dependencies occur when 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 on Microsoft.AspNetCore.Mvc.
Direct dependencies are discoverable by reviewing your project.json 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.Authentication package to your project, it depends on the Microsoft.AspNetCore.Http package (among others). This causes your project to have a direct dependency on Microsoft.AspNetCore.Authentication and a transitive dependency on the Microsoft.AspNetCore.Http package.
Transitive dependencies are reviewable in the Microsoft Visual Studio Solution Explorer window, which also supports search, or by reviewing the project.lock.json file contained in the root directory of your project. This file contains the authoritative list of packages for your project.
How do I fix my affected application?
You will need to fix both direct dependencies and review and fix any transitive dependencies. Version 1.0.1 of each of the vulnerable packages contains the fixes required to secure your application.

Fixing Direct Dependencies
To fix direct dependencies:
Open your project.json file in your editor. Look for the dependencies section. The following provides an example section:

“dependencies”: {
“Microsoft.NETCore.App”: {
“version”: “1.0.0”,
“type”: “platform”
},
“Microsoft.AspNetCore.Server.Kestrel”: “1.0.0”,
“Microsoft.AspNetCore.Mvc”: “1.0.0”,
}

In this example, there are three direct dependencies: Microsoft.NetCore.App, Microsoft.AspNetCore.Server.Kestrel and Microsoft.AspNetCore.Mvc.
Microsoft.NetCore.App is the platform that the application is targeted against, and it can be ignored. The other packages expose their version to the right of the package name. In this example, the non-platform packages are version 1.0.0.

Review your direct dependencies against the list of vulnerable packages in the Affected Software section of this advisory.
For each vulnerable package where there is a direct dependency, change the version number in your editor to 1.0.1. After updating all vulnerable package versions, save your project.json file.
The dependencies section in our example project.json file would now appear as follows:

“dependencies”: {
“Microsoft.NETCore.App”: {
“version”: “1.0.0”,
“type”: “platform”
},
“Microsoft.AspNetCore.Server.Kestrel”: “1.0.0”,
“Microsoft.AspNetCore.Mvc”: “1.0.1”,
}

If you are using Visual Studio and save your updated project.json file, the new version will be restored by Visual Studio. You can see the restore results by opening the Output Window (Ctrl+Alt+O), and then 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.

After you have addressed all of your direct dependencies, you are ready to review your transitive dependencies.

Reviewing Transitive Dependencies
There are two ways to view transitive dependencies: Use Visual Studio Solution Explorer, or review your project.lock.json file.

Using Visual Studio Solution Explorer
If you want to use Solution Explorer, open your project in Visual Studio, and then press Ctrl+; to activate the search in Solution Explorer. Search for each of the package names that are listed in the Affected Software section in this advisory, and make a note of any vulnerable packages that you find.
For example, searching for Microsoft.AspNetCore.Mvc in an example project that contains a package that takes a dependency on Microsoft.AspNetCore.Mvc displays the following results in the following figure.

Figure 1: Searching in Visual Studio

The search results appear as a tree. In the results, you can see the identified references. The first entry under the References heading refers to the target framework that your application is using. This will be .NETCoreApp, .NETStandard or .NET-Framework-vX.Y.Z (where X.Y.Z is an actual version number) depending on how you configured your application. Under your target framework the list of packages display that you have directly taken a dependency on. In this example, the application takes a dependency on VulnerablePackage. VulnerablePackage in turn has leaf nodes that list its dependencies and their versions. In this case, the package takes a dependency on a vulnerable version of Microsoft.AspNetCore.Mvc and others.

Manually Reviewing project.lock.json
Open the project.lock.json file in your editor. We suggest using an editor that understands json and that allows you to collapse and expand nodes to review this file. Both Visual Studio and Visual Studio Code provide this functionality.
If you are using Visual Studio, the project.lock.json file is “under” the project.json file. Click the right pointing triangle, ▷, to the left of the project.json file to expand the solution tree to expose the project.lock.json file. The following figure displays a project with the project.json file expanded to show the project.lock.json file.
3181759 - Vulnerabilities in ASP.NET Core View Components Could Allow Elevation of Privilege - Version: 1.0

Figure 2: project.lock.json file location

Search the project.lock.json files for the vulnerable packages that are listed in the Affected Software section of this advisory. For each package, take the package name, add a / and then append the version number. For example, Microsoft.AspNetCore.Mvc version 1.0.0 is represented in the project.lock.json file as “Microsoft.AspNetCore.Mvc/1.0.0”. Make a note of each package name that you find that matches an entry in the table in the Affected Software section of this advisory.

Fixing Transitive Dependencies
You may now have a list of affected packages. If you have not found any transient packages, then either none of your dependencies in turn depend on a vulnerable package, or you have already fixed the problem by updating the direct dependencies.
If your transitive dependency review has produced a list of vulnerable packages, then you must add a direct dependency to an updated version of each vulnerable package to your project.json file to override the transitive dependency. Open your project.json file and find the dependencies section. For example:

“dependencies”: {
“Microsoft.NETCore.App”: {
“version”: “1.0.0”,
“type”: “platform”
},
“Microsoft.AspNetCore.Server.Kestrel”: “1.0.0”,
“VulnerablePackage”: “1.0.0-*”
}

The results of the transitive package search show that VulnerablePackage depends on Microsoft.AspNet.Mvc version 1.0.0. To fix this example, you must add a direct dependency by adding it to the project.json file. You can do this by adding a new line to the dependencies section that refers to the fixed version. For example, to pull in the fixed version of Microsoft.AspNet.Mvc, version 1.0.1, edit the project.json file as follows:

“dependencies”: {
“Microsoft.NETCore.App”: {
“version”: “1.0.0”,
“type”: “platform”
},
“Microsoft.AspNetCore.Mvc”: “1.0.1”,
“Microsoft.AspNetCore.Server.Kestrel”: “1.0.0”,
“VulnerablePackage”: “1.0.0-*”
}

After adding direct dependencies to the fixed packages, save your project. json file.
If you are using Visual Studio, saving the updated project.json file stores the new versions in Visual Studio. To see the restore results, open the Output Window (Ctrl+Alt+O) and change 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.
You may want to check for transitive dependencies again to ensure that you have fixed all of them.

Rebuilding Your Application
Finally, rebuild your application, test it as you normally would, and then redeploy it using your favored deployment mechanism.

Leave a Reply