CVE-2024-38361

Executive Summary

CVE-2024-38361 is a vulnerability in SpiceDB, an open-source, Google Zanzibar-inspired permissions database. The flaw occurs when an exclusion is used under an arrow that has multiple resources. In such cases, the exclusion dispatcher may fail to request all relevant folders, leading to an incorrect NO_PERMISSION response when PERMISSION is expected. This can cause legitimate users to be denied access to resources they should be able to view. The vulnerability has a low CVSS score of 3.7, indicating limited impact, but it can disrupt authorization workflows. The patch is available in version 1.33.1.

Supply Chain & Package Security

SpiceDB is a Go-based package. Users should verify the integrity of the package by checking checksums and signatures from the official GitHub releases. The vulnerability is in the core authorization logic, not in a dependency, so supply chain risks are minimal.

CVSS Breakdown & Threat Level

• CVSS Score: 3.7 (Low)
• Vector: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L
• Attack Vector: Network
• Attack Complexity: High (requires specific conditions with multiple resources and exclusions)
• Privileges Required: Low (attacker needs some access)
• User Interaction: None
• Scope: Unchanged
• Confidentiality Impact: None
• Integrity Impact: None
• Availability Impact: Low (incorrect denial of access)

The threat level is low due to the specific conditions required and the limited impact (only availability of correct permissions is affected).

Deep Dive & Mechanics

SpiceDB uses a relationship-based access control model inspired by Google Zanzibar. The vulnerability lies in the exclusion dispatcher when processing arrow expressions with multiple resources. An arrow (->) in SpiceDB represents a relationship traversal. When an exclusion (e.g., NOT) is applied under an arrow that resolves to multiple resources (e.g., multiple folders), the dispatcher should request all those resources to determine permission. However, due to a bug, it may only request a subset, leading to an incorrect NO_PERMISSION result.

For example, consider a permission view on a document that is in multiple folders. If a user has view access to some but not all folders, and an exclusion is used to deny access based on folder membership, the dispatcher might only check one folder, incorrectly denying access.

The fix in version 1.33.1 ensures the exclusion dispatcher correctly requests all relevant resources.

Vulnerable vs. Patched Code

The vulnerable code is in the exclusion dispatcher logic. The exact code is not publicly available, but the patch modifies the dispatcher to iterate over all resources instead of stopping early.

Vulnerable (pseudocode):

func (d *ExclusionDispatcher) Dispatch(ctx context.Context, req *DispatchRequest) (*DispatchResult, error) {
    // Bug: Only processes first resource
    for _, resource := range req.Resources[:1] {
        // process exclusion
    }
    return result, nil
}

Patched (pseudocode):

func (d *ExclusionDispatcher) Dispatch(ctx context.Context, req *DispatchRequest) (*DispatchResult, error) {
    // Correctly processes all resources
    for _, resource := range req.Resources {
        // process exclusion
    }
    return result, nil
}

Exploitation & Lab Setup

Red Team

To exploit this vulnerability, an attacker would need to:

1. Have low-privilege access to a SpiceDB instance.
2. Create a permission model with an arrow that has multiple resources and an exclusion.
3. Craft a request that triggers the bug, causing a legitimate user to be denied access.

Lab Setup:

• Deploy SpiceDB version < 1.33.1.
• Create a schema with a document in multiple folders and a permission that uses an exclusion under an arrow.
• As an attacker, send a CheckPermission request for a user who should have access but is denied due to the bug.

Example request:

{
  "subject": "user:alice",
  "permission": "view",
  "resource": "document:secret"
}

Blue Team

To detect exploitation attempts:

• Monitor SpiceDB logs for unexpected NO_PERMISSION responses.
• Look for patterns where the same user is denied access to resources they previously accessed.
• Use the detection rules below.

Indicators of Compromise (IOCs)

• Log Entries: SpiceDB logs showing NO_PERMISSION for resources where the user should have PERMISSION.
• API Responses: Repeated CheckPermission responses with NO_PERMISSION for valid users.
• Network Traffic: Unusual patterns of permission checks from a single user.

Detection Engineering

YARA Rule

rule CVE_2024_38361_SpiceDB_Exclusion_Bug {
    meta:
        description = "Detects SpiceDB logs indicating exclusion dispatcher bug"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-38361"
    strings:
        $log1 = "NO_PERMISSION" nocase
        $log2 = "exclusion" nocase
        $log3 = "dispatcher" nocase
    condition:
        all of them
}

Sigma Rule

title: SpiceDB Exclusion Dispatcher Bug Detection
id: 8a9b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects potential exploitation of CVE-2024-38361 in SpiceDB logs
author: Valters IT
date: 2025-04-10
logsource:
    product: spicedb
    service: audit
detection:
    selection:
        EventID: "CheckPermission"
        Result: "NO_PERMISSION"
    condition: selection
falsepositives:
    - Legitimate permission denials
level: low

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-38361 SpiceDB Exclusion Bug"; flow:to_server; content:"CheckPermission"; http_uri; content:"NO_PERMISSION"; http_server_body; sid:1000001; rev:1;)

Remediation & Mitigation

1. Upgrade: Immediately upgrade to SpiceDB version 1.33.1 or later.
2. Workaround: No known workarounds exist. The only fix is to upgrade.
3. Monitoring: Enable detailed logging for permission checks and monitor for anomalies.
4. Access Control: Limit low-privilege access to SpiceDB to reduce attack surface.

Valters IT
DevSecOps & Cyber Threat Intelligence