GHSA-77hh-43cm-v8j6 json
tuf's Metadata API: Targets.get_delegated_role() is missing input validation
published 2y ago modified 2y ago
- cvss
- —
- not scored
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
The security of both a TUF client and repository implementations depend on the concept of trusted Metadata objects verifying the signatures over other Metadata that it delegates to. This verification process uses `Targets.get_delegated_role(delegated_role: str)` to find the delegation information.
`tuf.api.metadata.Targets.get_delegated_role()` should ensure that the given `delegated_rolename` is actually a name of a role that is delegated by that Targets, but in the case of "succinct delegation" this does not happen.
`tuf.ngclient` users are **not** impacted but direct users of `tuf.api.metadata` could be impacted.
### Impact
If an attacker can make a Metadata API user run `Targets.get_delegated_role()` so that 1. the `Targets` uses succinct delegation 1. the `delegated_role` argument is not actually delegated by the `Targets`
the result will be incorrect.
This also means that if an attacker can make a Metadata API user run `Targets.verify_delegate()` or `Targets.get_verification_result()` so that 1. the delegating `Targets` uses a succinct delegation 1. the `delegated_role` argument is the name of some unrelated Metadata 1. that other Metadata is correctly signed by the keys defined in the succinct delegation
the result would be a successful verification even though the `Targets` in question does not actually delegate to `delegated_role`.
The impact is estimated to be low for following reasons:
* This cannot impact a TUF client that implements the client workflow as specified since the delegated role name is not an input but is collected from the (trusted) delegating Targets itself * Actual signature verification is not bypassed: The verified metadata _must_ still be correctly signed by the keys specified in the delegating role. * The described situations are somewhat hypothetical: there does not seem to be any reason for a python-tuf user (whether client or a repository) to use `tuf.api.metadata` in this way.
All users of `tuf.ngclient` are specifically **not** impacted. Users of `tuf.api.metadata` could be impacted if they use succinct delegations in a way described above.
### Patches
A fix is available in python-tuf 3.1.1 as commit 77cb66bc and in later releases as commit eb4834d9._
### Workarounds
`tuf.api.metadata` users should only call `Targets.get_delegated_role()`, `Targets.verify_delegate()` or `Targets.get_verification_result()` with `delegated_role` argument that is known to be delegated by the `Targets` in question.
Patch / fix
- pypi tuf 3.1.1
Is GHSA-77hh-43cm-v8j6 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerAffected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| pypi | tuf | >=2.0.0, <3.1.1 |
3.1.1 |
References
-
github.com
/theupdateframework/python-tuf/commit/77cb66bc879d108c449ba4c46dfb0e3a9e57a785
web
-
github.com
/theupdateframework/python-tuf/commit/eb4834d9205d07ae164bc6c5b97787585c0acfdc
web
-
github.com
/theupdateframework/python-tuf/security/advisories/GHSA-77hh-43cm-v8j6
web
-
github.com
/theupdateframework/python-tuf
package
-
github.com
/theupdateframework/python-tuf/releases/tag/v3.1.1
web
Sources
- GitHub Advisory GHSA-77hh-43cm-v8j6
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.