Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

content: Update mitigation section for the Dependency Confusion threat. #1226

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

content: Update mitigation section for the Dependency Confusion threat. #1226

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
43bc3a4
Update mitigation section for the Dependency Confusion threat.
meder Oct 29, 2024
a75a5fe
Make href relative.
meder Oct 29, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 10 additions & 1 deletion docs/spec/draft/threats.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -775,9 +775,18 @@ The consumer requests a package that it did not intend.
on the victim's internal registry, and wait for a misconfigured victim to fetch
from the public registry instead of the internal one.

**TODO:** fill out the rest of this section
*Mitigation:* The mitigation is for the software producer to build internal
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

optional: Would we prefer to say that SLSA doesn't currently address this threat but that a future tracks plans to (insert relevant links)?

One reason we might prefer not to address this threat as written is that not all methods of forming expectations will address it. E.g. in 'verifying-artifacts' it talks about forming expectations and the first thing listed is TOFU. In the TOFU model this threat isn't addressed, we'd just wind up anchoring on the malicious package's provenance values. 'Defined in source' has a similar problems in that the package name is bound to a source repo, if the wrong name is requested then the malicious expectations will be pulled instead.

The only way of forming expectations that works here is "Defined by producer", but it's not clear how those expectations are communicated. You could imagine a similar one called 'defined by organization' where the org sets a policy that says "unless you get an exception for a package it must come from builds A, B, C and source repos X, Y, Z".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that this threat is very specifically about a public package shadowing a name from the internal registry, it would still be possible to enforce expectations on the internal-only packages at least since the producer and consumer is the same entity, I think? In other words, set expectations for package foo (known internal) in resolvedDependencies but not package bar which is fine to pull in from the external registry.

Separately, this might need a higher level of completeness in build provenance than is currently typical. For example, looking at NPM's use of provenance, resolvedDependencies doesn't record all the packages that are actually resolved but rather just the git revision. Should this be called out?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that this threat is very specifically about a public package shadowing a name from the internal registry, it would still be possible to enforce expectations on the internal-only packages at least since the producer and consumer is the same entity, I think? In other words, set expectations for package foo (known internal) in resolvedDependencies but not package bar which is fine to pull in from the external registry.

Right, that's a better way of describing what I was trying to get at with expectations that are set by the organization.

Separately, this might need a higher level of completeness in build provenance than is currently typical. For example, looking at NPM's use of provenance, resolvedDependencies doesn't record all the packages that are actually resolved but rather just the git revision. Should this be called out?

Not quite sure what you mean? That's all we need to address this threat as the source repo listed there is the 'main' one that drives the build itself (IIUC).

Or perhaps you're suggesting we call this out to the folks that build that NPM provenance because it's not complete? (it doesn't need to be at lower SLSA levels).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, that's a better way of describing what I was trying to get at with expectations that are set by the organization.

My bad, I misread the last bit of that comment. It's the same idea. 😄

Not quite sure what you mean? That's all we need to address this threat as the source repo listed there is the 'main' one that drives the build itself (IIUC).

If the provenance only records a git revision, we don't have sufficient information to enforce the "defined by organization" list for internal dependencies as the packages fetched by the dependency resolver for the manifest at that git revision is unknown.

In other words, in addition to saying SLSA level 2+ builder, maybe this text needs to call out that resolvedDependencies needs to be more complete to enforce the expectations about the organization's internal packages.

Copy link
Contributor

@TomHennen TomHennen Nov 5, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the provenance only records a git revision, we don't have sufficient information to enforce the "defined by organization" list for internal dependencies as the packages fetched by the dependency resolver for the manifest at that git revision is unknown.

Oooh, I think where we're getting wires crossed is when this is getting checked and at what scope.

My assumption is that here @meder is referring to the provenance of the dependency itself being checked. It sounds like you're thinking about it from the perspective of checking if something build with that dependency uses the bad thing.

Case 1 <--- This is what @meder is saying??

  1. External package 'foo' shadows internal package 'foo'.
  2. external-foo's provenance lists a single resolvedDependency showing that it was built from git+https://github.com/not-my-org/foo-js@refs/heads/main.
  3. The system that fetches 'foo' (somehow) knows that foo is internal and so it must have provenance that shows it was built from git+https://github.com/my-org or git+https://git.my-org.com.

Case 2 <--- This is what you're saying??

  1. External package 'foo' shadows internal package 'foo'.
  2. Internal package 'bar' is built using external-foo.
  3. bar has a good build that provides complete resolvedDependencies in it's provenance
  4. When bar is having its provenance checked the verifier can check to see that all packages we expect to be internal (somehow) come from the internal registry.

I think the biggest problem with this approach is actually figuring out which packages are internal and which aren't. Which is why it might be easier to just say "SLSA doesn't handle this now, but the dependency track will".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great discussion, thanks all.

Case 1 is indeed what I am describing with the caveat that the producer should be able to easily communicate/distribute the expectations to the consumers as the producer and the organization consuming dependencies are the same entity. The verification can then happen at different points in SDLC: it could happen at the time dependencies are ingested into the internal registry, it could happen on build/installation.

packages on a SLSA Level 2+ compliant build system and define expectations for
build provenance. Expectations must be verified on installation of the internal
packages. If a misconfigured victim attempts to install attacker's package with
Comment on lines +779 to +781
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to be more precise about what we mean by "define expectations for build provenance" here? It is not clear to me what expectations we are verifying.

Also, if we are doing verifications on the provenance, that is after the build, right? If so, it doesn't really follow for me to verify on installation. Are you trying to say that we must verify that internal packages are installed/used and not some untrusted external one?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checking 'expectations' is commonly used terminology on this page. The other threats mention it without further explanation. The explanation about how to do so is in https://slsa.dev/spec/v1.1/verifying-artifacts#step-2-check-expectations.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

re: the last question: yes.

an internal name but from the public registry, then verification against
expectations will fail.

For more information see [Verifying artifacts](/spec/v1.1/verifying-artifacts)
and [Defender's Perspective: Dependency Confusion and Typosquatting Attacks](/blog/2024/08/dep-confusion-and-typosquatting).

</details>

<details><summary>Typosquatting</summary>

*Threat:* Register a package name that is similar looking to a popular package
Expand Down