ghsa-4f8r-qqr9-fq8j
Vulnerability from github
Published
2024-10-01 18:13
Modified
2024-10-11 14:23
Severity ?
7.5 (High) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
8.7 (High) - CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Summary
Incorrect delegation lookups can make go-tuf download the wrong artifact
Details

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:

python "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.

Show details on source website

To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/theupdateframework/go-tuf/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-47534"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-10-01T18:13:25Z",
    "nvd_published_at": "2024-10-01T16:15:09Z",
    "severity": "HIGH"
  },
  "details": "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. \n\nWe have come across this issue in the test in this PR: https://github.com/theupdateframework/tuf-conformance/pull/115.\n\nThe 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](https://github.com/theupdateframework/tuf-conformance/pull/115#issuecomment-2275625542), the `two-level-delegations` test case triggered a wrong order. The delegations in this look as such:\n\n```python\n\"two-level-delegations\": DelegationsTestCase(\n        delegations=[\n            DelegationTester(\"targets\", \"A\"),\n            DelegationTester(\"targets\", \"B\"),\n            DelegationTester(\"B\", \"C\"),\n        ],\n        visited_order=[\"A\", \"B\", \"C\"],\n    ),\n```\n\nHere, `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\"-\u003e\"C\"-\u003e\"A\"`.\n\nIn a subsequent CI run, this test case did not fail, but [another one did](https://github.com/theupdateframework/tuf-conformance/pull/115#issuecomment-2275640487).\n\n@jku has done a bit of debugging and believes that the returned map of `GetRolesForTarget` returns a map that causes this behavior:\n\nhttps://github.com/theupdateframework/go-tuf/blob/f95222bdd22d2ac4e5b8ed6fe912b645e213c3b5/metadata/metadata.go#L565-L580\n\nWe believe that this map should be an ordered list instead of a map.",
  "id": "GHSA-4f8r-qqr9-fq8j",
  "modified": "2024-10-11T14:23:04Z",
  "published": "2024-10-01T18:13:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/theupdateframework/go-tuf/security/advisories/GHSA-4f8r-qqr9-fq8j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47534"
    },
    {
      "type": "WEB",
      "url": "https://github.com/theupdateframework/tuf-conformance/pull/115"
    },
    {
      "type": "WEB",
      "url": "https://github.com/theupdateframework/go-tuf/commit/edc30b474f5afd4cc603e17149704d5aa605151d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/theupdateframework/go-tuf/commit/f36420caba9edbfdfd64f95a9554c0836d9cf819"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/theupdateframework/go-tuf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/theupdateframework/go-tuf/blob/f95222bdd22d2ac4e5b8ed6fe912b645e213c3b5/metadata/metadata.go#L565-L580"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2024-3166"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Incorrect delegation lookups can make go-tuf download the wrong artifact"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.