search

dotnet / wcf

This repo contains the client-oriented WCF libraries that enable applications built on .NET Core to communicate with WCF services.
MIT License
1.72k stars 558 forks source link

CVE-2023-29331 - System.ServiceModel.Primitives6.2.0 - upgrade - System.Security.Cryptography.Xml6.0.1 to System.Security.Cryptography.Xml 8.0.1 #5611

Open rsrinivasanhome opened 4 months ago

rsrinivasanhome commented 4 months ago

Describe the bug CVE-2023-29331 is related to System.ServiceModel.Primitives6.2.0 in the following manner nuget: System.ServiceModel.Primitives/6.2.0 refers - nuget: System.Security.Cryptography.Xml/6.0.1 refers - nuget: System.Security.Cryptography.Pkcs/6.0.1

image

https://github.com/dotnet/announcements/issues/257

image

CVE-2023-29331 - refers - nuget: System.Security.Cryptography.Pkcs/6.0.1

upgrade - System.Security.Cryptography.Xml6.0.1 to System.Security.Cryptography.Xml 8.0.1

mconnew commented 3 months ago

We don't have a direct dependency on Pkcs so it wouldn't be appropriate for us to add an artificial dependency raising the version higher to satisfy security tooling that is running against an app that's consuming our package.

The System.Security.Cryptography.Xml package hasn't released a new version with an updated dependency because any security vulnerabilities in Pkcs (or Asn1 which Pkcs refernces and has vulnerably versions) aren't being hit by code in System.Security.Cryptography.Xml. We are referencing the latest 6.x version of System.Security.Cryptography.Xml so there isn't a later version for us to reference. Referencing 8.x package versions from a package intended to be used on .NET 6 has a tendency to break builds. For example, if an app is directly referencing an earlier version of the same package, you will get a build error about having downgraded the dependency.

Basically there's no real security risk due to any vulnerable code not being executed. If a newer version of System.Security.Cryptography.Xml is released, we would probably need to release a new version of our packages.

There's a recent blog post describing options on how to resolve this in your own application. My crib notes version is for now use central package management with transitive pinning.

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

Daniel-Svensson commented 2 months ago

@mconnew just my thoughs on the issue here

  1. The root cause is that you are still dependeing on the .NET6 version (6.0.x) for both the .NET7+ and .NET8 builds of System.ServiceModel.* nugets.

  2. While .NET 6 nugets should work you should at least include the versions developed and tested for .NET8 for System.ServiceModel.* 8.0.x. (6.0 will soon be out of support).

  3. With the new Nuget Audit features in .NET 8 (where it can) and 9 where it will report security issues with transitive dependencies anyone including System.ServiceModel.* can/will get build warnings. I really expect a lot more from Microsoft supplied nugets using the System namespace, for example SqlClient and EFCore (just as most popular oss nugets) regulary update and ensure dependencies and transitive does not include vulnerable version.

As a consumer I want to be able to add a reference to System.ServiceModel.Primitives to a .NET 9 or .NET 8 project and build it without getting warnings during restore or build.

Mertsch commented 1 month ago

If a newer version of System.Security.Cryptography.Xml is released, we would probably need to release a new version of our packages.

This is exactly the way .NET 6/7/8 are released. This seems to be a strong indicator to go exactly that route. Have .NET 6 TFM use the latest .NET 6 packages and the 8 TFM use the latest 8 packages.

Daniel-Svensson commented 1 month ago

This is exactly the way .NET 6/7/8 are released. This seems to be a strong indicator to go exactly that route. Have .NET 6 TFM use the latest .NET 6 packages and the 8 TFM use the latest 8 packages.

Agree. In this case it is quite easy no need to do fancy stuff and keep different versions per target framework, just keep all direct nuget dependencies up to date (use dependabot or do it manually before each release).

The latest version of System.Security.Cryptography.Xml (8.0.2 at the time of this writing) supports .NET6 + so it would make senes to use that depedency for all currently supported nuget versions/target frameworks, (it would have made senes to update even the older 6.0 + releases if it ware not for the fact that .NET 6 will soon reach end of life)