[SECURITY] new version of Azure.Extensions.AspNetCore.DataProtection.Blobs to combat dependency security vulnerability please

[robrich]

Library name and version

Azure.Extensions.AspNetCore.DataProtection.Blobs 1.3.4

Describe the bug

Azure.Extensions.AspNetCore.DataProtection.Blobs depends on ... depends on System.Drawing.Common 4.7.0 which has a critical vulnerability, causing a build warning. Can we get a new build of Azure.Extensions.AspNetCore.DataProtection.Blobs that depends on the recently released version of Microsoft.AspNetCore.DataProtection that doesn't have this vulnerability?

Expected behavior

Build succeeds without warnings.

Actual behavior

Build fails when "Treat warnings as Errors" is enabled, and NuGet package restore fails.

Reproduction Steps

1. Add Azure.Extensions.AspNetCore.DataProtection.Blobs NuGet package
2. See NuGet security error
3. Cry

Environment

ASP.NET 9, VS 2022

[github-actions]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[jsquire]

Hi @robrich. Thanks for reaching out and we regret that you're experiencing difficulties. This traces back to System.Security.Permissions v4.7.0, which has a dependency on System.Windows.Extensions only for its netcoreapp3.0 target. Neither its netstandard2.0 or net461 targets hold that dependency. This has been discussed this with the Azure SDK and .NET security teams and they confirmed that this is considered a false positive by the scanner rather than an active security risk, as the issue being flagged exists only for an unsupported platform. If you have a need to mitigate the false positive, the recommendation is to take a direct dependency on a version of Microsoft.AspNetCore.DataProtection in your application that is not flagged by the scanner.

Unfortunately, we're out of minor versions of Microsoft.AspNetCore.DataProtection to move to and moving to a new major version requires additional validation and testing. We're tracking this work in #35707, but I don't currently have an estimate on when we'll have bandwidth to schedule work on it.

Related:

• #35693
• #42102

[github-actions]

Hi @robrich. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text "/unresolve" to remove the "issue-addressed" label and continue the conversation.

[robrich]

Is there a way to store DataProtection keys in Azure Storage without this library?

Can we update the docs at https://learn.microsoft.com/en-us/dotnet/api/overview/azure/extensions.aspnetcore.dataprotection.blobs-readme and https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/implementation/key-storage-providers to note the additional dependency to avoid the security error?

[jsquire]

Is there a way to store DataProtection keys in Azure Storage without this library?

I can't speak authoritatively to the Data Protection system in general, but I believe the answer is yes. Anyone can write a provider similar to the extension package and implement the persistence contract to store keys in Azure Storage.

 

Can we update the docs at https://learn.microsoft.com/en-us/dotnet/api/overview/azure/extensions.aspnetcore.dataprotection.blobs-readme and https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/implementation/key-storage-providers to note the additional dependency to avoid the security error?

We appreciate the suggestion, but this would cause more confusion than help. There is no need for direct references in your application when hosted on any supported version of .NET. The only time there's a potential vulnerability that needs to be mitigated is if you're running on netcoreapp3.0 specifically - which is an unsupported framework. The correct mitigation in that case is to upgrade to a supported runtime, not redeploy with updated references.

With respect to the security error that you're seeing, its a known false positive returned by several third-party scanners. These are not legitimate security vulnerabilities. When last we spoke about it, the .NET security team is aware and was in discussions with several of the third-party tooling providers to offer advice for correcting the error. Unfortunately, that is not something that the maintainers of the Azure SDK packages have deeper insight into nor influence over.

[SoftwareJourney]

@jsquire "With respect to the security error that you're seeing, its a known false positive returned by several third-party scanners."
=> I don't think it is only related to third-party scanners. It also affects Visual Studio (without third-party extension).

In Visual Studio v17.12.1, when I add the nuget package "Azure.Extensions.AspNetCore.DataProtection.Keys" v1.2.4 to an empty class library project (dotnet v8), I almost instantly get the following compilation warning:
"Package 'System.Drawing.Common' 4.7.0 has a known critical severity vulnerability, GHSA-rxg9-xrhp-64gj"

[robrich]

This is my exact scenario as well. Visual Studio 2022 with no extensions and an ASP.NET 9 app. Taking a dependency on the intermediate library solved the symptom.