Решение, ориентированное на .NET Core 2.1, строится со старыми System.ServiceModel.Primitives и System.Private.ServiceModel - PullRequest
0 голосов
/ 01 сентября 2018

У меня есть решение, состоящее из проектов, нацеленных на .NET Standard 2.0 и .NET Core 2.1.304. При создании этого решения используются старые уязвимые версии System.ServiceModel.Primitives и System.Private.ServiceModel ( CVE-2018-0786 ).

Возможно, мне не хватает чего-то очевидного в конфигурации всего решения или в одном из проектов, который вызывает использование старых версий, но все, что я знаю для проверки, выглядит правильно:

Global.json

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

Пример .NET Core Project File

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

Пример стандартного файла проекта .NET

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

Я убедился, что все пакеты NuGet обновлены. Тем не менее, возможно ли, что одна из моих ссылок на пакет NuGet вызывает откат к старым версиям? Какие еще конфигурации я должен проверять?


Интересно, что когда я собираю другое, но схоже сконфигурированное решение (из того, что я могу сказать), это решение создает сборку с использованием более новых не уязвимых версий.

1 Ответ

0 голосов
/ 04 сентября 2018

Вы можете использовать инструмент, такой как dotnet-outdated , чтобы определить как ваши версии зависимостей, так и транзитивные зависимости в вашем проекте.

Установить через dotnet tool install --global dotnet-outdated в командной строке powershell и запустите 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 и изучить каждую подозрительную зависимость, чтобы увидеть, какую версию зависимостей она использует.

...