Fixing Transitive Dependency Vulnerabilities Best Practices

Fixing Transitive Dependency Vulnerabilities
Transitive Dependency

Today in this article, we will cover guidelines on Fixing Transitive Dependency Vulnerabilities.

Today in this article, we will cover below aspects,

In our last article on Transitive dependencies in .NET Core, we understood on basics of transitive dependencies. We understood Transitive dependency occurs when your project reference a package that in turn uses or references another package.

For example:

You add a package B to your project A that in turn relies on another package C. So here A-B shows a direct dependency whereas the A-C relationship is transitive in nature.

So here in this scenario,

  • A has a Direct dependency on “B”
  • A has a Transitive dependency on “C”

Based on the above understanding most of the .NET Core system DLLs are Transitive in nature. These transitive dependencies versions will rely on the parent version. If you fix the parent version, transitive will follow that fix accordingly.

How to fix Direct/Transitive Dependencies vulnerabilities?

There is a difference between direct and transitive dependency. I discussed this in the last article on the same.

One can use any of below discussed generic approaches for fixing vulnerabilities issues below but not limited to,

  • Information Disclosure Vulnerability
  • Denial of Service Vulnerability in .NET Core
  • NET Core Domain Spoofing Vulnerability etc.

Fixing Direct Dependencies

Let’s understand how to fix direct dependencies.

I have a .NET Core console application that uses System.Net.Http 4.3.0 version which is found to be vulnerable as per the CVE research report.

Open the project file(.csproj) file in any editor of your choice.

Vulnerable package referenced

The below example shows a single direct dependency on System.Net.Http version 4.3.0 which is found to be vulnerable.

<project sdk="Microsoft.NET.Sdk">
  <propertygroup>
    <outputtype>Exe</outputtype>
    <targetframework>netcoreapp2.2</targetframework>
  </propertygroup>
  <itemgroup>
    <packagereference include="System.Net.Http" version="4.3.0">
  </packagereference></itemgroup>
</project>

Vulnerable package fixed

Let’s change the version to the secured package version in the project file as below,

<project sdk="Microsoft.NET.Sdk">
  <propertygroup>
    <outputtype>Exe</outputtype>
    <targetframework>netcoreapp2.2</targetframework>
  </propertygroup>
  <itemgroup>
    <packagereference include="System.Net.Http" version="4.3.5">
  </packagereference></itemgroup>
</project>


Fixing Transitive Dependencies

The below project file shows a .NET Core 2.2 application that uses a transitive dependency named System.Net.Http 4.3.0 version.

This package is found to be vulnerable as per CVE research report.

Here is the project file for .NET Core WebAPI,

<project sdk="Microsoft.NET.Sdk.Web">
  <propertygroup>
    <targetframework>netcoreapp2.2</targetframework>
    <aspnetcorehostingmodel>InProcess</aspnetcorehostingmodel>
  </propertygroup>
  <itemgroup>
    <packagereference include="Microsoft.AspNetCore.App">
  </packagereference></itemgroup>
</project>

Transitive dependencies can be viewed using multiple options like as below,

How to View Transitive Dependency

If Using Visual Studio .NET

One can easily view transitive dependency in any Visual Studio version like VS2019

2. .NET Core Tooling

dotnet command provides an easy and convenient option to list all package references including direct and transitive dependencies for a specific project.

Command

Below is a flag “–include-transitive” which can be used for getting the list of Transitive dependencies.

dotnet list package --include-transitive

The above figure shows limited transitive dependencies due to the size of the figure.

3. Using project.assets.json

This file gets generated after compiling and building in the obj directory of your project. This is also a good option to view dependencies.

Resolution – Vulnerable package fixed

Resolution- I

Once you identify your package to be fixed using any of the above methods, to fix the transitive dependency, you must add a dependency to the updated version of the vulnerable package by adding it to the .csproj file. i.e such a vulnerable package needs to be made a direct dependency of your main project.

As we found our search showed a transitive reference to a vulnerable “System.Net.Http” version 4.3.0.

blank

As per Microsoft advisory https://github.com/dotnet/corefx/issues/34428# report version secured version “System.Net.Http” version 4.3.5 should be used.

With the above understanding let’s update the project file(.csproj) file by using the updated version i.e 4.3.5 of the vulnerable package.

<project sdk="Microsoft.NET.Sdk.Web">
  <propertygroup>
    <targetframework>netcoreapp2.2</targetframework>
    <aspnetcorehostingmodel>InProcess</aspnetcorehostingmodel>
  </propertygroup>
  <itemgroup>
    <packagereference include="Microsoft.AspNetCore.App">
    <packagereference include="System.Net.Http" version="4.3.5">
  </packagereference></packagereference></itemgroup>
</project>

Tips :

It’s preferred to keep your projects up to date with any new of .NET Core version and new patches. Every new .NET Core version or patch brings new features or provides minor bug fixes along with vulnerabilities fixed.

Opting major .NET Core version could address and fix the most transitive dependency issue as well.

After the project file update, please run the build and perform a vulnerability scan of your project. You shall see your Transitive dependency issue got resolved successfully.

Above apporach can be applied if Tranistive dependency vulnerabilities is coming through Third-party or Vendor projects.

It becomes your responsibility that such vulenarabilties are fixed.

Resolution II

The above approach of the direct reference of the affected library although it will fix the vulnerabilities issues, sometimes projects the team might find it difficult to update the project references due to the risk of incompatibility with the latest packages.

Let’s not forget that .NET Core is still evolving, it’s changing with every version.

Let’s imagine if there are hundreds of such projects in your portfolios?

Upgrading Framework version

It’s recommended to target the latest version of .NET Core SDK and Runtime.

Target the latest patch

If a major framework upgrade is not possible for example .NET Core 2.1 to .NET Core 2.2 then one can target the latest patch version of the given .NET Core version.

Most open-source framework libraries follow semantic versioning. This versioning has great support in helping you deciding proper approaches.

blank

As per my understanding patch version carries a few advantages,

  • They are safe to use.
  • Most vulnerabilities fix bug fixes and other small improvements. often comes through a patched version.
  • Very unlikely they might cause incompatibility or other issues.
  • It doesn’t need an update to the project file configuration. Changes will be limited to the upgrade to the hosting environment. If using the cloud as a hosting environment similar measures can be done on pipeline performing containerization of binaries often through build server.

Tip and guidelines :

In my recent analysis, I found that even after upgrading to the latest .NET Core framework project in Visual Studio was still referencing old .NET Core framework and vulnerable libraries. However, the issue got resolved once after uninstalling the old version of .NET Core SDK.

I am not sure if this is right behaviour and this is how .NET Core works versioing works. Just to mention, I do not wanted to use the approach of using global.json with the latest framework version but wanted the framework to pull the right versions of libraries.

Resolution III- Add Global.json

You can target specific .NET Core versions easily by adding a global.json file.

Example:

{
  "sdk": {
    "version": "2.2.100",
  }

}

The global.json file allows you to define the target .NET Core SDK version is used when you run .NET Core CLI commands.

This is a simple and easy approach to dealing with framework upgrades.

Keep the door open for the new framework version.

You should build the process to take advantage of any latest patches around open source vulnerabilities.

However, a lot depends on how your organization builds a proper process around managing and fixing such issues.

As a good measure, you should keep track of vulnerabilities.

There are multiple COTS products available that help you find the vulnerabilities in open-sourced libraries like Appscan, WhiteSource, Blackduck, etc.

For example, GitHub already has inbuilt support for discovering and notifying new vulnerabilities on Open source libraries referenced in your project.

Please sound off your comments below for any suggestions or inputs.

Summary

Today in this article we looked at a few approaches to fix vulnerabilities issues in the Transitive dependency in the .NET Core framework. Buggy code slipping through the cracks has the potential to cost a company an entire business if such issues are ignored or not remediated at the earliest.



Please bookmark this page and share it with your friends. Please Subscribe to the blog to receive notifications on freshly published(2024) best practices and guidelines for software design and development.



2 thoughts on “Fixing Transitive Dependency Vulnerabilities Best Practices

  1. Hi Rosika, thanks for the feedback . This issue is quite common as . Net Core is open sourced.
    To fix the issue please add the non vulnerable version on your project file directly. This will override third party referenced package by default.
    Other approach would to ask third party dll vendor to use latest SDK with patch version. Your project should require upgrade too to accommodate the changes. Hope this helps. Thanks

  2. Hi – Thanks for useful insight. We have .net Core 2.1app using a third party package. This is in turn referencing in another the package which is vulnerable. What is the best approach to fix it ?

Leave a Reply

Your email address will not be published. Required fields are marked *