针对.NET Core 2.1构建的解决方案,使用旧版的System.ServiceModel.Primitives和System.Private.ServiceModel。

4
我有一个解决方案,由.NET Standard 2.0和.NET Core 2.1.304项目组成。构建此解决方案时,使用了旧的易受攻击版本的System.ServiceModel.PrimitivesSystem.Private.ServiceModel(CVE-2018-0786)。
我可能错过了总体解决方案或其中一个项目的配置,导致使用旧版本,但我所知道要检查的所有内容都正确无误:

Global.json

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

.NET Core项目文件示例

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

示例 .NET Standard 项目文件

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

我已确保所有 NuGet 包都是最新的。但是,是否有可能我的某个 NuGet 包引用导致回退到旧版本?我应该检查哪些其他配置?

有趣的是,当我构建一个不同但类似配置的解决方案(据我所知)时,该解决方案会使用较新的、非易受攻击的版本进行构建。
1个回答

2
您可以使用诸如dotnet-outdated的工具来确定项目中依赖项和传递依赖项的版本。
通过在 PowerShell 命令行中执行dotnet tool install --global dotnet-outdated进行安装, 然后在解决方案文件夹中运行dotnet outdated -t -td 100来查看100级传递依赖项。
您的输出将类似于以下内容。
» 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

您可以使用上述过时的依赖项来追踪需要进一步调查的解决方案中的哪些项目。

从那里开始,消除已知安全的依赖项,因为它们出现在其他没有对坏库(无论版本如何)有依赖的项目中。此时可能需要使用 nuget.org 并调查每个可疑的依赖项,查看其使用的子依赖项的版本。


你的回答让我找到了解决方案的路径。最终,两个解决方案都引用了一个有问题的包。然而,那个没有问题的解决方案也引用了一个包,导致它选择了一个更新的、没有问题的版本的 System.ServiceModel.Primitives。除了 dotnet-outdated 这个优秀的工具可以确定哪个过时的引用被添加到了你的解决方案中,还有一个非常有用的工具叫做 dotnet-depends。不幸的是,它目前只能按项目而不是按解决方案来使用,但仍然非常有用。 - ahsteele

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接