GHSA-5hcj-rwm6-xmw4

Suggest an improvement
Source
https://github.com/advisories/GHSA-5hcj-rwm6-xmw4
Import Source
https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2024/07/GHSA-5hcj-rwm6-xmw4/GHSA-5hcj-rwm6-xmw4.json
JSON Data
https://api.osv.dev/v1/vulns/GHSA-5hcj-rwm6-xmw4
Aliases
Published
2024-07-31T18:48:40Z
Modified
2024-11-25T05:24:39.778738Z
Severity
  • 3.0 (Low) CVSS_V3 - CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:N/I:L/A:N CVSS Calculator
  • 5.1 (Medium) CVSS_V4 - CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N CVSS Calculator
Summary
biscuit-java vulnerable to public key confusion in third party block
Details

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?

Database specific
{
    "nvd_published_at": "2024-08-01T22:15:28Z",
    "cwe_ids": [
        "CWE-1259"
    ],
    "severity": "MODERATE",
    "github_reviewed": true,
    "github_reviewed_at": "2024-07-31T18:48:40Z"
}
References

Affected packages

Maven / org.biscuitsec:biscuit

Package

Name
org.biscuitsec:biscuit
View open source insights on deps.dev
Purl
pkg:maven/org.biscuitsec/biscuit

Affected ranges

Type
ECOSYSTEM
Events
Introduced
3.0.0
Fixed
4.0.0

Affected versions

3.*

3.0.0
3.0.1