面向 .NET Core 2.1 的解决方案使用旧的 System.ServiceModel.Primitives 和 System.Private.ServiceModel 构建

Question

I have a solution made up of projects targeting .NET Standard 2.0 and .NET Core 2.1.304. When built this solution utilizes old vulnerable versions of System.ServiceModel.Primitives and System.Private.ServiceModel ( CVE-2018-0786 ).

I am probably missing something obvious about the configuration of the overall solution or one of the projects that is causing the utilization of the old versions, but everything I know to check looks correct:

Global.json

{
  "sdk": {
    "version": "2.1.302"
  }
}

Example .NET Core Project File

<PropertyGroup>
  <TargetFramework>netcoreapp2.1</TargetFramework>
  <Configurations>Debug;Dev;Qual;Release</Configurations>
  <LangVersion>7.1</LangVersion>
</PropertyGroup>

Example .NET Standard Project File

<PropertyGroup>
  <TargetFramework>netstandard2.0</TargetFramework>
  <Configurations>Debug;Dev;Qual;Release</Configurations>
</PropertyGroup>

I have ensured all NuGet packages are up to date. That said is it possible that one of my NuGet package references is causing a fallback to the old versions? What other configurations should I be checking?

---

_{Interestingly when I build a different, but similarly configured solution (from what I can tell) that solution produces a build using the newer non vulnerable versions.}

Answer 1

You can use a tool such as dotnet-outdated to determine both your the versions of your dependencies and transitive dependencies in your project.

Install via dotnet tool install --global dotnet-outdated on the powershell command line and run dotnet outdated -t -td 100 in your solution folder to see 100 levels of transitive dependencies.

Your output will look something like the following

» MyProject
  [.NETCoreApp,Version=v2.1]
  System.Private.ServiceModel [T]                 4.4.0  -> 4.5.3
  System.ServiceModel.Primitives [T]              4.4.0  -> 4.5.3

You can then use the above stated out of date dependencies to track down which project(s) in your solution needs to be further investigated.

From there eliminate dependencies that are known to be safe, as they appear in other projects that don't have a dependency on the bad library (regardless of version). At this point it may be a matter of using nuget.org and investigating each suspect dependency to see what version of sub-dependencies it uses.