GitHub Advisoryadvisory · crates.io
GHSA-p9w4-585h-g3c7 biscuit-auth vulnerable to public key confusion in third party block
LOW
Official page ↗
- Aliases
- CVE-2024-41949
- Ecosystem
- crates.io
- Packages
- biscuit-auth
- Severity
- Low
- CVSS vector
- CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:N/I:L/A:N
- Weaknesses
- CWE-269
- Reviewed
- 2024-07-31
Affected packages
• crates.io biscuit-auth: >= 4.0.0, < 5.0.0 → fixed in 5.0.0
Description
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
Related
Alias · CVE (1)
- CVE-2024-41949 biscuit-rust is the Rust implementation of Biscuit, an authentication and authorization token for microservices architectures. vulnerability
Weakness · CWE (1)
- CWE-269 Improper Privilege Management weakness