Skip to content

Public key confusion in third party block

Low
Geal published GHSA-rgqv-mwc3-c78m Jul 31, 2024

Package

cargo biscuit-auth (Rust)

Affected versions

4

Patched versions

5.0.0
maven org.biscuitsec.biscuit (Maven)
3
4
specification (Biscuit)
3
4

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

Severity

Low

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
High
Privileges required
High
User interaction
None
Scope
Changed
Confidentiality
None
Integrity
Low
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:N/I:L/A:N

CVE ID

CVE-2024-42350

Weaknesses

No CWEs