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

Attacker goals #35

Closed
wants to merge 6 commits into from
Closed

Attacker goals #35

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
4c0dc2c
Added attacker goals
JustinCappos May 1, 2020
a0e372a
Update threatmodel.md
JustinCappos May 4, 2020
85deb58
Update threatmodel.md
JustinCappos Apr 13, 2021
2f1c198
Update threatmodel.md
JustinCappos Apr 13, 2021
b1762a8
Update threatmodel.md
JustinCappos Apr 13, 2021
5e2a17b
Update threatmodel.md
JustinCappos Apr 13, 2021
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
12 changes: 12 additions & 0 deletions threatmodel.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,3 +10,15 @@ It is assumed that an attacker may perform one or more the following actions:

While it is not always possible to protect against all scenarios, the system should to the extent possible mitigate and/or reduce the damage caused by a successful attack, detect the occurrence of an attack and notify appropriate parties, yet remain usable for parties operating the system. Furthermore, the system should recover from successful attacks in a way that presents low operational overhead and risk to users.

Attacker Goals:
1. To have a party deploy a malicious artifact under the attacker's control.
2. Trying to have a party install an outdated image. For example, one with known security vulnerabilities.
Copy link
Contributor

Choose a reason for hiding this comment

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

Change "an outdated image" to "an image who's signature has been revoked by the signer" or something to that effect. That avoids us defining what outdated is, leaving the definition up to the signer to determine and implement according to their own policies.

Copy link
Contributor Author

@mnm678 mnm678 Apr 12, 2021 •
edited
Loading

Choose a reason for hiding this comment

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

Suggested change
2. Trying to have a party install an outdated image. For example, one with known security vulnerabilities.
2. To have a party deploy an artifact using a digest or tag that does not have a currently valid signature. For example, a previous version of an artifact with a signature that was revoked by the signer, or an old version associated with a tag.

Copy link

Choose a reason for hiding this comment

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

This changes the meaning a bit. The prior also would include artifacts that were not the latest (when the latest is requested), but this seems to imply those are fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I updated my change. In some cases, someone might pull an old image by digest on purpose, and as long as the signature is still valid, this should be accepted, which is the subtlety I was trying to add. But yes, it still needs to use the latest tag mapping when tags are used.

3. Making images unavailable for installation.
Copy link
Contributor

Choose a reason for hiding this comment

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

For Notary, we could phrase this "Disrupt the verification of image signatures."

Copy link
Contributor

Choose a reason for hiding this comment

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

images - artifacts

Copy link
Contributor Author

@mnm678 mnm678 Apr 12, 2021 •
edited
Loading

Choose a reason for hiding this comment

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

Suggested change
3. Making images unavailable for installation.
3. Disrupt the verification of artifact signatures, for example by making the current version of metadata unavailable.

Copy link
Contributor

Choose a reason for hiding this comment

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

image - artifact

Copy link

Choose a reason for hiding this comment

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

This is a bit more specific. I don't know if it matters, but it reads like your text is a special case of mine...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was trying to make it clear that DoS attacks are out of scope, but there might be a better way to word this.

4. Prevent a party from learning about updates to currently installed artifacts.
5. Convince a party to download large amounts of data, such as signatures or metadata, that interfere with the party's system.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is covered by the size already listed in the registry, so is probably out of scope for Notary

6. Enable future attacks of the above types to be carried out more easily. For example, by causing a party to trust the attacker's key.

## Out of Scope
The following attacks are considered out of scope for Notary v2:
1. Denial of Service (DoS) attacks.
2. Registry validation. A registry may choose to do validation when artifacts are uploaded, but this validation is out of scope of Notary v2.