System.Security.Cryptography.Pkcs 8.0.1 package needed to resolve System.Formats.Asn1 vulnerability

[KirkMunroSagent]

Description

If you take a dependency on System.Security.Cryptography.Pkcs 8.0, you will receive a package vulnerability warning due to the vulnerability identified in #104622. That warning occurs because System.Security.Cryptography.Pkcs 8.0 has a dependency on System.Formats.Asn1 >= 8.0.0, and System.Formats.Asn1 8.0.0 is the vulnerable package. System.Formats.Asn1 8.0.1 is available, and no longer contains the vulnerability.

To fix this without requiring customers to take a dependency on a nested package that isn't directly referenced in their code (customers should not have to do that), Microsoft should publish a System.Security.Cryptography.Pkcs 8.0.1 package that has a dependency on System.Formats.Asn1 >= 8.0.1.

Reproduction Steps

1. Create a .NET 8 project that takes a dependency on the latest System.Security.Cryptography.Pkcs 8.x package.
2. Compile your project in Visual Studio.

Expected behavior

The project will compile without any package vulnerability warnings.

Actual behavior

The project compiles, and Visual Studio identifies that you have vulnerable packages.

Regression?

No

Known Workarounds

Take a hard dependency on System.Formats.Asn1 8.0.1.

NOTE: Taking a dependency on a nested package that you do not reference in your code really isn't a viable workaround, because it adds something else to manage that may very well not be cleaned up later, and it's a transient dependency, so really the package that does reference it and use it directly needs to be updated. That's the proper fix.

Configuration

.NET 8.0
Windows 11
x64

This issue is not specific to Windows or x86/x64.

Other information

1. It would be really nice if the NuGet Package Manager would properly identify packages that have internal dependencies that contain known vulnerabilities so that customers have someone to reach out to when a package like System.Security.Cryptography.Pkcs needs an update. Finding this so that I could come here to log the bug required opening up the obj/project.assets.json file and inspecting the contents to determine where the vulnerability warning was really coming from.

[vcsjones]

/cc @ViktorHofer and @ericstj. This looks like duplicate of #98827 but with different packages.

[KirkMunroSagent]

@vcsjones: Thank you for drawing my attention to #98827. I had missed that when I searched for an existing issue.

Having read that issue, and the pushback against updating these packages, I thought I should share some additional perspective.

When a customer like myself takes a dependency on one of the packages that internally takes a dependency on System.Formats.Asn1, and when you use Visual Studio to build your solution, here is what the end-user experience currently looks like:

1. Once the vulnerability in System.Formats.Asn1 is published, you are presented with the following warning in Visual Studio:

   

2. If you click on the Manage Nuget Packages link that is presented in the UI, you're taken to the NuGet Package Manager in Visual Studio. The NuGet Package Manager does not identify any package that you have as vulnerable. You need to look in the error log to see what warnings appear that highlight which package is vulnerable.

3. Once you see which package is vulnerable, since the vulnerable package is a transitive package that you didn't directly add to your project, you need to figure out where that vulnerability comes from using some other means. In my case, I had to open the obj/project.assets.json file to figure it out.

   In this case, it's from the System.Security.Cryptography.Pkcs 8.0.0 package, because that package lists System.Formats.Asn1 >= 8.0.0 as a dependency, so anyone that needs System.Security.Cryptography.Pkcs in .NET 8 will currently take on a package that is vulnerable to a DDOS attack, by default (as was highlighted in the other issue).

The proposed solution seems to be for customers to take on an additional dependency, even though they don't use it directly. This is taking something that could be fixed in one location, at the root, by simply publishing a System.Security.Cryptography.Pkcs 8.0.1 package with a System.Format.Asn1 >= 8.0.1 dependency, and pushing that work out to every project, current and new, that uses this package. How that is acceptable as a proposed solution is baffling. You're literally telling your customers to fix your problem for you, individually, per project. It's a remarkably irresponsible way to handle a security vulnerability.

I'm going to wait for a reply to see if this can be changed, but if the policy is to do nothing in this scenario, that policy needs to be revisited, full stop. Your tooling (Visual Studio and the Nuget Package Manager within it) doesn't properly help customers understand the problem, and your proposed solution doesn't address the problem in such a way that customers can easily get the vulnerability repaired. How is doing nothing in this scenario, with inadequate tooling leaving customers to have to dig around to figure out what is really going on, considered an acceptable solution?

[WGroenestein]

Over the past couple of years, our csproj files have become littered with comments like these (it is our solution to say, we don't really want this direct dependency, but we have too, so don't delete it)

<!-- We take a direct dependency on System.Formats.Asn1 because the transitive version used by other dependencies is marked as vulnerable #{issue-number} -->

In terms of addressing these errors, we have found that the dotnet cli is the easiest to figure things out (though it will not report vulnerable versions which have been unlisted (which is another issue))

dotnet list package --vulnerable --include-transitive

This is how we deal with the tools givens (though not ideal indeed)

[KirkMunroSagent]

Over the past couple of years, our csproj files have become littered with comments like these

I find that so unfortunate, for something that could be so easily resolved at the root via a simple NuGet package update.

dotnet list package --vulnerable --include-transitive

I use the same command, but that just tells me which packages are vulnerable. It doesn't identify why I'm seeing the vulnerability (i.e. if it's transitive, what is the source of the problem so that I can ping the source if they're not addressing it properly). Running the same command without --include-transitive isn't any more helpful either. So far, the best way I've found to identify the source of the vulnerability is by reviewing the obj/projects.assets.json file. I'm going to write a script to automate that, because I'm simply not willing to blindly convert transitive dependencies to direct dependencies without knowing exactly which packages are the real culprit. If in the future we drop a dependency that was the true source of the problem, I don't want any dependencies that should be unnecessary left kicking around, so I need to include those packages in the comments as well so that I can keep my dependency list as short as possible over time.

[KirkMunroSagent]

Maybe the proper solution for Microsoft is to use floating version dependencies for Microsoft-managed packages so that the latest appropriate version is installed instead of the minimum version, which may contain vulnerabilities.

i.e. Instead of having a dependency in System.Security.Cryptography.Pkcs on System.Format.Asn1 >= 8.0.0, set that dependency up as System.Format.Asn1 >= 8.*. If you take that approach, the Nuget Package resolver should pull down the latest 8.* version that is available, allowing for packages containing vulnerabilities to be flagged accordingly and automatically superseded as those vulnerabilities are fixed.

That means you would need to publish a single System.Security.Cryptography.Pkcs package update, bringing it up to 8.0.1, but from that point forward if you don't need to make direct updates, indirect updates would automatically be picked up. As long as you limit your floating version updates to the packages that you (Microsoft) controls, and as long as no breaking changes are published within the same major version number, that would solve this problem. You could use >= 8.0.* instead of >= 8.* if you are more risk averse, because there should definitely not be any breaking changes in a 8.0.* update.

If all of that makes you too uncomfortable due to no direct testing of the updates, then I don't see another solution other than to stand behind your packages by doing the right thing and updating them when there are vulnerabilities in your dependencies. The testing argument doesn't stand up though because by not updating you're telling customers to take on these updates themselves, and expecting that to work for them, so floating version dependencies seems like the right way to go since that's essentially what you're counting on working in this situation anyway.

[WGroenestein]

I suspect this is what would be very useful to have: NuGet/Home#11553 (or something similar to npm ls)

[JonDouglas]

hey folks,

we recently blogged on this topic and how nuget can help you further on understanding transitive vulnerabilities:

https://devblogs.microsoft.com/nuget/nugetaudit-2-0-elevating-security-and-trust-in-package-management/

[KirkMunroSagent]

Thanks @JonDouglas, sounds like some great improvements are on their way that will make this much easier.

Based on what I read, it seems like the Supplied By Platform would make for smart elimination of some of the recent package vulnerabilities (System.Text.Json, System.Format.Asn1), as long as you have the appropriate SDK version with the fixes installed, correct? It looks like that's been in progress since 2018, so maybe there's still some opportunity to address vulnerability issues in the meantime by using floating version dependencies if that future update won't see the light of day for some time yet? It's great if it will be resolved in the future, but it seems like a bad decision to leave things the way they are in the meantime.

[idontsov]

@jeffhandley added this to the Future milestone 2 days ago
Work on this milestone may or may not occur; it is not confirmed.

Updates to packages are not released unless there are changes within the packages themselves.

Instead of issuing a minor update to the package, you are requiring your customers to find a workaround and hope for the eventual delivery of the Supplied By Platform feature.

Could you please explain why it is challenging for you to release a minor package update?

[KirkMunroSagent]

@jeffhandley: I'd like to know more about the decision to tag this with the Future milestone as well.

You have a package that you offer to customers. Your package is dependent on another package that has a known vulnerability/exploit. Any of your customers that use your package automatically pick up that exploit.

Solutions already exist to solve this at the lowest level, so that your customers get the exploit fixed/corrected without needing to take on additional package dependencies that they shouldn't have to take on. One of those solutions (floating version dependencies) also allows for future exploits that show up in the packages that you are dependent on to be fixed, such that a customer would simply need to rebuild their project to get fixes to those packages as well.

Yet instead of addressing this fixable issue with an update to your package, Microsoft's recommended solution is for each customer to fix this issue themselves, because of an internal policy that seems like it should be revisited and revised, with a plan in place to fix this at some time in the future once some new functionality that has been in progress since 2018 is released and adopted.

Is that the outcome of this issue? And that's ok?

If so, I'll deal with it simply because I don't have a choice, but it certainly doesn't seem like a very responsible way to handle vulnerabilities in packages that have fixes available.