CVE-2024-23820

Executive Summary

CVE-2024-23820 is a denial of service (DoS) vulnerability in OpenFGA, an open-source authorization/permission engine. The flaw resides in the ListObjects API endpoint, where under specific model and tuple configurations, memory is not properly released after processing a request. An attacker can exploit this by sending a high volume of such requests, causing the OpenFGA server to exhaust available memory and terminate with an out-of-memory (OOM) error. This results in a denial of service condition, impacting the availability of the authorization service. The vulnerability affects versions prior to 1.4.3, and the fix is included in version 1.4.3.

Supply Chain & Package Security

OpenFGA is a Go-based project. The vulnerability is in the core server logic, not in a specific package dependency. However, organizations using OpenFGA as a dependency in their own Go applications should ensure they update to version 1.4.3 or later to mitigate the risk. The official OpenFGA Docker images and binary releases should also be updated.

CVSS Breakdown & Threat Level

• CVSS Score: 5.3 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
• Attack Vector: Network (AV:N) – The vulnerability can be exploited remotely.
• Attack Complexity: Low (AC:L) – No special conditions are required.
• Privileges Required: None (PR:N) – No authentication is needed.
• User Interaction: None (UI:N) – No user action is required.
• Scope: Unchanged (S:U) – The impact is confined to the vulnerable component.
• Confidentiality Impact: None (C:N) – No data exposure.
• Integrity Impact: None (I:N) – No data modification.
• Availability Impact: Low (A:L) – The service can be terminated, causing a denial of service.

Threat Level: Medium. While the CVSS score is moderate, the ease of exploitation (no authentication, low complexity) and the potential for service disruption make it a significant concern for production environments.

Deep Dive & Mechanics

The vulnerability is a memory leak in the ListObjects endpoint. When processing certain requests, the server allocates memory for internal data structures (e.g., for caching or intermediate results) but fails to deallocate it after the request completes. Over time, repeated calls to ListObjects with specific model and tuple combinations cause memory consumption to grow unboundedly.

The root cause is likely a missing defer or explicit cleanup call for resources allocated during the ListObjects execution. The specific conditions that trigger the leak depend on the authorization model and the tuples stored in the system. For example, models with deeply nested relationships or large sets of tuples may exacerbate the issue.

When the server's memory limit is reached, the Go runtime triggers an out-of-memory (OOM) condition, causing the process to crash. This results in a denial of service for all clients relying on the OpenFGA service.

Vulnerable vs. Patched Code

The patch in version 1.4.3 addresses the memory leak by ensuring proper cleanup of resources after each ListObjects call. The exact code changes are not publicly detailed, but the fix likely involves adding defer statements to release allocated memory or using a context with a timeout to prevent resource accumulation.

Vulnerable Code (Conceptual):

func (s *Server) ListObjects(ctx context.Context, req *openfgapb.ListObjectsRequest) (*openfgapb.ListObjectsResponse, error) {
    // Allocate memory for internal processing
    cache := make(map[string]interface{})
    // ... processing logic that may not release cache ...
    return response, nil
}

Patched Code (Conceptual):

func (s *Server) ListObjects(ctx context.Context, req *openfgapb.ListObjectsRequest) (*openfgapb.ListObjectsResponse, error) {
    // Allocate memory for internal processing
    cache := make(map[string]interface{})
    defer func() {
        // Explicitly release memory
        for k := range cache {
            delete(cache, k)
        }
    }()
    // ... processing logic ...
    return response, nil
}

Exploitation & Lab Setup

Red Team

Objective: Cause a denial of service by exhausting memory on the OpenFGA server.

Prerequisites:

• Access to the OpenFGA API endpoint (e.g., http://target:8080).
• Knowledge of a valid authorization model and tuple that triggers the leak.

Steps:

1. Identify the OpenFGA server and its API endpoint.
2. Create or use an existing authorization model that includes complex relationships (e.g., nested union or intersection).
3. Insert a large number of tuples that match the model's conditions.
4. Send repeated ListObjects requests with parameters that trigger the memory leak. For example:

   for i in $(seq 1 10000); do
       curl -X POST "http://target:8080/list-objects" \
           -H "Content-Type: application/json" \
           -d '{"type": "document", "relation": "viewer", "user": "user:alice"}'
   done
   

5. Monitor the server's memory usage. If the leak is triggered, memory will increase until the process crashes.

Expected Outcome: The OpenFGA server terminates with an OOM error, causing a denial of service.

Blue Team

Objective: Detect and mitigate the exploitation attempt.

Detection:

• Monitor memory usage of the OpenFGA process. A steady increase in memory consumption over time is a strong indicator.
• Monitor API logs for a high volume of ListObjects requests from a single source IP.
• Set up alerts for OOM events in the system logs.

Mitigation:

• Apply the patch by upgrading to OpenFGA version 1.4.3 or later.
• Implement rate limiting on the ListObjects endpoint to reduce the impact of a DoS attack.
• Use resource limits (e.g., cgroups) to prevent the OpenFGA process from consuming all system memory.
• Deploy a Web Application Firewall (WAF) to block suspicious traffic patterns.

Indicators of Compromise (IOCs)

• Network: High volume of POST requests to /list-objects endpoint.
• System: OOM killer logs in /var/log/syslog or dmesg showing the OpenFGA process being killed.
• Memory: Continuous increase in memory usage of the openfga-server process.
• Logs: OpenFGA server logs showing repeated ListObjects calls with the same parameters.

Detection Engineering

YARA Rule

rule CVE_2024_23820_OpenFGA_Memory_Leak {
    meta:
        description = "Detects OpenFGA server binary vulnerable to CVE-2024-23820"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-23820"
    strings:
        $vuln_func = "ListObjects"
        $vuln_version = "1.4.2" // Example vulnerable version string
    condition:
        $vuln_func and $vuln_version
}

Sigma Rule

title: High Volume of ListObjects Requests to OpenFGA
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects a high number of ListObjects requests which may indicate exploitation of CVE-2024-23820
author: Valters IT
logsource:
    category: application
    product: openfga
detection:
    selection:
        event: "ListObjects"
    timeframe: 5m
    condition: selection | count() > 1000
falsepositives:
    - Legitimate high usage of the API
level: medium

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-23820 OpenFGA ListObjects DoS Attempt"; flow:to_server; content:"POST"; http_method; content:"/list-objects"; http_uri; threshold: type both, track by_src, count 100, seconds 60; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate:

• Upgrade OpenFGA to version 1.4.3 or later. This is the only official fix.
• If immediate upgrade is not possible, implement rate limiting on the ListObjects endpoint to reduce the attack surface.

Long-term:

• Monitor OpenFGA releases for security patches and apply them promptly.
• Implement resource limits (e.g., memory limits via cgroups) for the OpenFGA process.
• Use a reverse proxy or API gateway to add additional security controls.
• Conduct regular security audits of the OpenFGA configuration and usage.

Workarounds:

• Restrict access to the ListObjects endpoint to trusted clients only.
• Use network segmentation to limit exposure of the OpenFGA service.

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Expert