Skip to content

Conversation

@jonpryor
Copy link
Contributor

@jonpryor jonpryor commented Feb 9, 2021

Context: https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610
Context: https://azure.microsoft.com/en-us/resources/3-ways-to-mitigate-risk-using-private-package-feeds/
Context: https://devdiv.visualstudio.com/DevDiv/_wiki/wikis/DevDiv.wiki/12676/ncident-help-for-Substitution-attack-risk-from-multiple-package-feeds

There is a Package Substitution Attack inherent in NuGet, whereby
if multiple package sources provide packages with the same name,
it is indeterminate which package source will provide the package.

For example, consider the XliffTasks package, currently
provided from the dotnet-eng feed, and not present in the
NuGet.org feed. If a "hostile attacker" submits an XliffTasks
package to NuGet.org, then we don't know, and cannot control, whether
the build will use the "hostile" XliffTasks package from NuGet.org
or the "desired" package from dotnet-eng.

There are two ways to prevent this attack:

  1. Use //packageSources/clear and have only one
    //packageSources/add entry in NuGet.config

  2. Use //packageSources/clear and fully trust every
    //packageSources/add entry in NuGet.config.
    NuGet.org cannot be a trusted source, nor can any feed
    location which allows "anyone" to add new packages, nor can
    a feed which itself contains upstream sources.

As the XliffTasks package is not in NuGet.org, option (1)
isn't an option. Go with option (2), using the existing
dotnet-eng source and the new trusted dotnet-public
package source.

Context: https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610
Context: https://azure.microsoft.com/en-us/resources/3-ways-to-mitigate-risk-using-private-package-feeds/
Context: https://devdiv.visualstudio.com/DevDiv/_wiki/wikis/DevDiv.wiki/12676/ncident-help-for-Substitution-attack-risk-from-multiple-package-feeds

There is a Package Substitution Attack inherent in NuGet, whereby
if multiple package sources provide packages with the same name,
it is *indeterminate* which package source will provide the package.

For example, consider the [`XliffTasks` package][0], currently
provided from the [`dotnet-eng`][1] feed, and *not* present in the
NuGet.org feed.  If a "hostile attacker" submits an `XliffTasks`
package to NuGet.org, then we don't know, and cannot control, whether
the build will use the "hostile" `XliffTasks` package from NuGet.org
or the "desired" package from `dotnet-eng`.

There are two ways to prevent this attack:

 1. Use `//packageSources/clear` and have *only one*
    `//packageSources/add` entry in `NuGet.config`

 2. Use `//packageSources/clear` and *fully trust* every
    `//packageSources/add` entry in `NuGet.config`.
    `NuGet.org` *cannot* be a trusted source, nor can any feed
    location which allows "anyone" to add new packages, nor can
    a feed which itself contains [upstream sources][2].

As the `XliffTasks` package is *not* in `NuGet.org`, option (1)
isn't an option.  Go with option (2), using the existing
`dotnet-eng` source and the new *trusted* [`dotnet-public`][3]
package source.

[0]: https://github.com/dotnet/xliff-tasks
[1]: https://dev.azure.com/dnceng/public/_packaging?_a=feed&feed=dotnet-eng
[2]: https://docs.microsoft.com/en-us/azure/devops/artifacts/concepts/upstream-sources?view=azure-devops
[3]: https://dev.azure.com/dnceng/public/_packaging?_a=feed&feed=dotnet-public
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant