CVE-2024-47534 for github.com/theupdateframework/go-tuf 0.7.0

[onelapahead]

Description

Using cosign, sigstore, and rekor as Go dependencies in our tooling, our CVE scanners (trivy / AquaDB) has flagged a new HIGH CVE that states:

The go-tuf client inconsistently traces the delegations. For example, if targets delegate to A, and to B, and B delegates to C, then the client should trace the delegations in the order A then B then C but it may incorrectly trace the delegations B->C->A.

https://avd.aquasec.com/nvd/2024/cve-2024-47534/

Looking at the code briefly, the issue that rekor still uses 0.7.0 of TUF rather than migrating to TUF 2.x (which it looks like cosign has upgraded to). Its unclear how complex this upgrade would be, and if theres any migration involved.

Questions

1. Can the maintainers explain how users might be affected and/or vulnerable ?
2. What is the timeline to this being patched ? Once its patched, is there any migration involved for users? Based on Proposal to deprecate unused Rekor kinds in public instance: alpine, rpm, rfc3161, jar, tuf #2080, there was hope of deprecating TUF use ?

NOTE: I did not go through the vulnerability disclosure process because 1) this CVE is already publicly disclosed, 2) its not clear if rekor is actually impacted by this CVE.

[haydentherapper]

This vulnerability does not affect rekor.

We will leave this open as we investigate upgrading to go-TUF v2.

[onelapahead]

Awesome thank you @haydentherapper !

[sinke237]

Hi @onelapahead ,
Thank you for pointing this out.
I previously contacted the maintainers of aquasec/trivy about this issue.
Their response was that they need to wait for rekor to update from v0.7.0 to v2.0.1 (which includes the fix).
Given my passion for resolving this issue, I continued my research and found this forum.

Hi @haydentherapper ,
I'm reaching out to clarify your statement regarding the vulnerability not affecting rekor. While you mentioned it doesn't impact rekor, I found several rekor files referencing github.com/theupdateframework/go-tuf v0.7.0 (see attached screenshot).
PS: I have not made any modification to the indicated branch on the screenshot

My passion for this issue led me here, and I'd appreciate your insights on this matter.

[haydentherapper]

go-tuf v0.7.0 is not affected by the vulnerability. I've discussed this with the go-tuf maintainers and they'll be updated the GHSA.

Even if v0.7.0 was affected, our usage of go-tuf in Rekor does not use the vulnerable API. We won't be prioritizing an update to go-tuf v2 as the type will be deprecated - #2080