Lucene search

K
githubGitHub Advisory DatabaseGHSA-4F8R-QQR9-FQ8J
HistoryOct 01, 2024 - 6:13 p.m.

Incorrect delegation lookups can make go-tuf download the wrong artifact

2024-10-0118:13:25
CWE-362
GitHub Advisory Database
github.com
4
tuf conformance test
bug
go-tuf
security implications
delegation tracing
artifact download
ci run
delegation order

CVSS3

0

Attack Vector

NETWORK

Attack Complexity

LOW

Privileges Required

NONE

User Interaction

NONE

Scope

UNCHANGED

Confidentiality Impact

NONE

Integrity Impact

NONE

Availability Impact

NONE

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N

CVSS4

8.2

Attack Vector

NETWORK

Attack Complexity

LOW

Privileges Required

NONE

User Interaction

NONE

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/SC:N/VI:H/SI:N/VA:N/SA:N

AI Score

6.8

Confidence

High

During the ongoing work on the TUF conformance test suite, we have come across a test that reveals what we believe is a bug in go-tuf with security implications. The bug exists in go-tuf delegation tracing and could result in downloading the wrong artifact.

We have come across this issue in the test in this PR: https://github.com/theupdateframework/tuf-conformance/pull/115.

The test - test_graph_traversal - sets up a repository with a series of delegations, invokes the clients refresh() and then checks the order in which the client traced the delegations. The test shows that the go-tuf client inconsistently traces the delegations in a wrong way. For example, during one CI run, the two-level-delegations test case triggered a wrong order. The delegations in this look as such:

"two-level-delegations": DelegationsTestCase(
        delegations=[
            DelegationTester("targets", "A"),
            DelegationTester("targets", "B"),
            DelegationTester("B", "C"),
        ],
        visited_order=["A", "B", "C"],
    ),

Here, targets delegate to "A", and to "B", and "B" delegates to "C". The client should trace the delegations in the order "A" then "B" then "C" but in this particular CI run, go-tuf traced the delegations "B"->"C"->"A".

In a subsequent CI run, this test case did not fail, but another one did.

@jku has done a bit of debugging and believes that the returned map of GetRolesForTarget returns a map that causes this behavior:

https://github.com/theupdateframework/go-tuf/blob/f95222bdd22d2ac4e5b8ed6fe912b645e213c3b5/metadata/metadata.go#L565-L580

We believe that this map should be an ordered list instead of a map.

Affected configurations

Vulners
Node
theupdateframeworkgo-tufRange<2.0.1
VendorProductVersionCPE
theupdateframeworkgo-tuf*cpe:2.3:a:theupdateframework:go-tuf:*:*:*:*:*:*:*:*

CVSS3

0

Attack Vector

NETWORK

Attack Complexity

LOW

Privileges Required

NONE

User Interaction

NONE

Scope

UNCHANGED

Confidentiality Impact

NONE

Integrity Impact

NONE

Availability Impact

NONE

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N

CVSS4

8.2

Attack Vector

NETWORK

Attack Complexity

LOW

Privileges Required

NONE

User Interaction

NONE

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/SC:N/VI:H/SI:N/VA:N/SA:N

AI Score

6.8

Confidence

High

Related for GHSA-4F8R-QQR9-FQ8J