GHSA-P9W4-585H-G3C7
Vulnerability from github – Published: 2024-07-31 21:15 – Updated: 2024-08-05 21:14Third-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
Aemits 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
Bgenerates the following third-party blockthirdparty("b"); check if thirdparty("c") trusting ${pubkeyC} - The token holder now must obtain a third-party block from third party
Cto 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
{
"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"
}
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.