Timestamp rollback check should also check for snapshot rollback #106
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This updates section 5.2.2 to also state that when updating the `timestamp` role, we should also check to make sure new `timestamp` role's `snapshot` version is greater than or equal to the trusted `timestamp`'s `snapshot` version. This is an important check when initializing a TUF database. For example, say we had the following TUF metadata: * `root`, which has signed all the below metadata * `snapshot` version 1, which points at a target with a compromised package * `snapshot` version 2, which points at a target with a fixed package * `timestamp` version 2, which points at snapshot version 2 Lets say an attacker has stolen the `timestamp` keys, they could forge a new `timestamp` role which points at `snapshot` version 1. In the normal case where we have a fully initialized TUF database with a trusted `root`, `timestamp` version 2, and `snapshot` version 2, this malicious timestamp would get rejected because of the section 5.3.2 snapshot rollback check. However, consider a partially initialized repository, where we only trust `root` and `timestamp` version 2, and for some reason were not able to fetch the rest of the metadata. In this setup, we won't have a trusted `snapshot` available for the 5.3.2 rollback check. Thus, the rollback attack would succeed. To fix this, I've adopted the language in section 5.3.3, where when updating the `snapshot` role, we do explicitly check to see if the listed `targets` or any delegated `targets` version is always greater than or equal to the trusted versions of those roles.
lukpueh
reviewed
Aug 27, 2020
There was a problem hiding this comment.
Thanks for the addition and the detailed commit message, @erickt! This definitely makes sense. It would be nice if we could land it together with the strongly related #86, which clarifies/fleshes out rollback prevention for delegated targets in a similar fashion, and updates the corresponding parts about ffwd-recovery. (mind taking a look?).
I left one only mildly related inline comment here, which is not a blocker for this PR. Still curious what others think.
Expiration has nothing to do with the rollback check, so it's not necessary to state this in section 5.2 for timestamps, and 5.3 for snapshots.
lukpueh
approved these changes
Aug 31, 2020
erickt
added a commit
to erickt/rust-tuf
that referenced
this pull request
Sep 18, 2020
This implements TUF-1.0.5 section 5.2.2.2, where when updating the timestamp role, we reject the new timestamp if the snapshot version it points at is older than the currently trusted snapshot role. See theupdateframework/specification#106 for more details. Closes theupdateframework#294 Change-Id: I4fb68aaf61ad8c0e3ffc0439095f5d00e5baa116
erickt
added a commit
to erickt/tuf-specification
that referenced
this pull request
Sep 23, 2020
This shares the same justification for removal as theupdateframework#65. Step 3.3.1 was made redundant by theupdateframework#106, which modified the workflow to add 2.2.2, where updating the timestamp will also check if the new timestamp contains a snapshot version that is less than the trusted snapshot version. This, in combination with the 3.1 check that asserts hashes and version of the actual snapshot metadata match the ones in the new trusted timestamp, make another version check, i.e, the one removed in this commit, obsolete.
erickt
added a commit
to erickt/rust-tuf
that referenced
this pull request
Oct 8, 2020
This implements TUF-1.0.5 section 5.2.2.2, where when updating the timestamp role, we reject the new timestamp if the snapshot version it points at is older than the currently trusted snapshot role. See theupdateframework/specification#106 for more details. Closes theupdateframework#294 Change-Id: I4fb68aaf61ad8c0e3ffc0439095f5d00e5baa116
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This updates section 5.2.2 to also state that when updating the
timestamprole, we should also check to make sure newtimestamprole'ssnapshotversion is greater than or equal to the trustedtimestamp'ssnapshotversion.This is an important check when initializing a TUF database. For example, say we had the following TUF metadata:
root, which has signed all the below metadatasnapshotversion 1, which points at a target with a compromised packagesnapshotversion 2, which points at a target with a fixed packagetimestampversion 2, which points at snapshot version 2Lets say an attacker has stolen the
timestampkeys, they could forge a newtimestamprole which points atsnapshotversion 1. In the normal case where we have a fully initialized TUF database with a trustedroot,timestampversion 2, andsnapshotversion 2, this malicious timestamp would get rejected because of the section 5.3.2 snapshot rollback check.However, consider a partially initialized repository, where we only trust
rootandtimestampversion 2, and for some reason we're not able to fetch the rest of the metadata. In this setup, we won't have a trustedsnapshotavailable for the 5.3.2 rollback check. Thus, the rollback attack would succeed.To fix this, I've adopted the language in section 5.3.3, where when updating the
snapshotrole, we do explicitly check to see if the listedtargetsor any delegatedtargetsversion is always greater than or equal to the trusted versions of those roles.