Lucene search

K
osvGoogleOSV:GHSA-5HCJ-RWM6-XMW4
HistoryJul 31, 2024 - 6:48 p.m.

biscuit-java vulnerable to public key confusion in third party block

2024-07-3118:48:40
Google
osv.dev
4
biscuit-java
third-party block
public key
vulnerability
token
datalog expressions
authority
fix

CVSS3

5

Attack Vector

NETWORK

Attack Complexity

LOW

Privileges Required

LOW

User Interaction

NONE

Scope

CHANGED

Confidentiality Impact

NONE

Integrity Impact

LOW

Availability Impact

NONE

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:N

AI Score

3.7

Confidence

High

EPSS

0

Percentile

14.5%

Impact

Tokens with third-party blocks containing trusted annotations generated through a third party block request. Due to implementation issues in biscuit-java, third party block support in published versions is inoperating. Nevertheless, to synchronize with other implementations, we publish this advisory and the related fix.

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.

Patches

Has the problem been patched? What versions should users upgrade to?

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

References

Are there any links users can visit to find out more?

CVSS3

5

Attack Vector

NETWORK

Attack Complexity

LOW

Privileges Required

LOW

User Interaction

NONE

Scope

CHANGED

Confidentiality Impact

NONE

Integrity Impact

LOW

Availability Impact

NONE

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:N

AI Score

3.7

Confidence

High

EPSS

0

Percentile

14.5%

Related for OSV:GHSA-5HCJ-RWM6-XMW4