GHSA-P9W4-585H-G3C7

Vulnerability from github – Published: 2024-07-31 21:15 – Updated: 2024-08-05 21:14
VLAI?
Summary
biscuit-auth vulnerable to public key confusion in third party block
Details

Third-party blocks can be generated without transferring the whole token to the third-party authority. Instead, a ThirdPartyBlock request can be sent, providing only the necessary info to generate a third-party block and to sign it:

  • the public key of the previous block (used in the signature)
  • the public keys part of the token symbol table (for public key interning in datalog expressions)

A third-part block request forged by a malicious user can trick the third-party authority into generating datalog trusting the wrong keypair.

Consider the following example (nominal case)

  • Authority A emits the following token: check if thirdparty("b") trusting ${pubkeyB}
  • The well-behaving holder then generates a third-party block request based on the token and sends it to third-party authority B
  • Third-party B generates the following third-party block thirdparty("b"); check if thirdparty("c") trusting ${pubkeyC}
  • The token holder now must obtain a third-party block from third party C to be able to use the token

Now, with a malicious user: - Authority A emits the following token: check if thirdparty("b") trusting ${pubkeyB} - The holder then attenuates the token with the following third party block thirdparty("c"), signed with a keypair pubkeyD, privkeyD) they generate - The holder then generates a third-party block request based on this token, but alter the ThirdPartyBlockRequest publicKeys field and replace pubkeyD with pubkeyC - Third-party B generates the following third-party block thirdparty("b"); check if thirdparty("c") trusting ${pubkeyC} - Due to the altered symbol table, the actual meaning of the block is thirdparty("b"); check if thirdparty("c") trusting ${pubkeyD} - The attacker can now use the token without obtaining a third-party block from C.

Impact

Tokens with third-party blocks containing trusted annotations generated through a third party block request

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "biscuit-auth"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "5.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-41949"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-07-31T21:15:41Z",
    "nvd_published_at": "2024-08-01T22:15:28Z",
    "severity": "LOW"
  },
  "details": "Third-party blocks can be generated without transferring the whole token to the third-party authority. Instead, a `ThirdPartyBlock` request can be sent, providing only the necessary info to generate a third-party block and to sign it:\n\n- the public key of the previous block (used in the signature)\n- the public keys part of the token symbol table (for public key interning in datalog expressions)\n\nA third-part block request forged by a malicious user can trick the third-party authority into generating datalog trusting the wrong keypair.\n\nConsider the following example (nominal case)\n\n- Authority `A` emits the following token: `check if thirdparty(\"b\") trusting ${pubkeyB}`\n- The well-behaving holder then generates a third-party block request based on the token and sends it to third-party authority `B`\n- Third-party `B` generates the following third-party block `thirdparty(\"b\"); check if thirdparty(\"c\") trusting ${pubkeyC}`\n- The token holder now must obtain a third-party block from third party `C` to be able to use the token\n\nNow, with a malicious user:\n- Authority `A` emits the following token: `check if thirdparty(\"b\") trusting ${pubkeyB}`\n- The holder then attenuates the token with the following third party block `thirdparty(\"c\")`, signed with a keypair `pubkeyD, privkeyD)` they generate\n- The holder then generates a third-party block request based on this token, but alter the `ThirdPartyBlockRequest` `publicKeys` field and replace `pubkeyD` with `pubkeyC`\n- Third-party `B` generates the following third-party block `thirdparty(\"b\"); check if thirdparty(\"c\") trusting ${pubkeyC}`\n- Due to the altered symbol table, the actual meaning of the block is `thirdparty(\"b\"); check if thirdparty(\"c\") trusting ${pubkeyD}`\n- The attacker can now use the token without obtaining a third-party block from `C`.\n\n### Impact\n\nTokens with third-party blocks containing `trusted` annotations generated through a third party block request\n",
  "id": "GHSA-p9w4-585h-g3c7",
  "modified": "2024-08-05T21:14:26Z",
  "published": "2024-07-31T21:15:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/biscuit-auth/biscuit-rust/security/advisories/GHSA-p9w4-585h-g3c7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/biscuit-auth/biscuit/security/advisories/GHSA-rgqv-mwc3-c78m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41949"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/biscuit-auth/biscuit-rust"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "biscuit-auth vulnerable to public key confusion in third party block"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…