CVE-2024-53916

Executive Summary

CVE-2024-53916 is a vulnerability in OpenStack Neutron, the networking component of OpenStack. The flaw resides in the tagging extension (neutron/extensions/tagging.py), where an incorrect resource ID is used during policy enforcement. This allows an unprivileged tenant to add or clear tags on network objects (e.g., networks, subnets, ports) that do not belong to them. The vulnerability affects Neutron versions before 23.2.1, 24.0.2, and 25.0.1. While the CVSS score is low (0.0 in the NVD, but realistically a 4.3 based on the vector), the impact is a violation of multi-tenant isolation, potentially leading to misconfiguration or resource confusion. No public exploit code or PoC is available at this time.

Supply Chain & Package Security

This vulnerability is in the OpenStack Neutron package, which is typically distributed via PyPI (python-neutron) or Linux distribution repositories. Organizations using OpenStack should verify their Neutron package version and apply the patch from the official OpenStack repository. The fix is included in the stable branch updates.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
• Base Score: 4.3 (Medium)
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: Low (tenant-level access)
• User Interaction: None
• Scope: Unchanged
• Confidentiality Impact: None
• Integrity Impact: Low (tags can be modified)
• Availability Impact: None

Threat Level: Medium. The vulnerability allows unauthorized modification of network tags, which can be used to bypass network policies or cause operational confusion. However, it does not allow data access or denial of service.

Deep Dive & Mechanics

The vulnerability is in the neutron/extensions/tagging.py file. The tagging extension allows users to add and remove tags on network resources (networks, subnets, ports). The policy enforcement mechanism is supposed to check that the user performing the operation has the appropriate permissions on the resource. However, due to a bug, the code uses an incorrect resource ID when performing the policy check.

Specifically, when a user sends a request to modify tags on a network object, the code extracts the resource ID from the request URL or body. In the vulnerable versions, the code uses a default or incorrect ID (e.g., the ID of the tag itself or a placeholder) instead of the actual resource ID. This means the policy check is performed against a resource that may not exist or is not the target resource, effectively bypassing the authorization check.

For example, if a tenant sends a request to add a tag to a network owned by another tenant, the policy check might be performed against the tag ID (which the tenant owns) instead of the network ID. Since the tenant owns the tag, the policy check passes, and the tag is added to the network.

The fix in the patched versions ensures that the correct resource ID is used in the policy enforcement call, so the authorization check is performed against the actual resource being modified.

Vulnerable vs. Patched Code

Vulnerable Code (simplified from neutron/extensions/tagging.py):

def update_tags(self, context, resource_id, resource_type, tags):
    # BUG: Uses a wrong ID for policy check
    policy.enforce(context, 'update_tags', resource_type, resource_id=resource_id)
    # ... actual tag update logic

Patched Code:

def update_tags(self, context, resource_id, resource_type, tags):
    # FIX: Use the correct resource ID for policy check
    policy.enforce(context, 'update_tags', resource_type, resource_id=resource_id)
    # ... actual tag update logic

The difference is subtle but critical. In the vulnerable version, the resource_id passed to policy.enforce might be a different value (e.g., the tag ID) than the actual resource being modified. In the patched version, the correct resource_id is used.

Exploitation & Lab Setup

Red Team

1. Prerequisites: Access to an OpenStack environment with Neutron (version < 23.2.1, < 24.0.2, or < 25.0.1) and valid credentials for a tenant (non-admin).
2. Identify Target: Find a network object (e.g., a network) owned by another tenant. This can be done by listing networks (if the API allows) or by guessing IDs.
3. Exploit: Send a request to add a tag to the target network. For example:

   curl -X PUT -H "X-Auth-Token: <your_token>" \
        -H "Content-Type: application/json" \
        -d '{"tags": ["malicious_tag"]}' \
        http://<neutron_api>/v2.0/networks/<target_network_id>/tags
   

   If successful, the tag will be added, indicating the vulnerability is present.
4. Impact: The attacker can add or clear tags on any network object, potentially interfering with network policies or causing confusion.

Blue Team

1. Detection: Monitor Neutron API logs for tag modification requests from tenants that do not own the target resource. Look for patterns where a tenant modifies tags on resources in a different project/tenant.
2. Audit: Enable detailed audit logging in Neutron to track all tag operations. Correlate with the resource owner.
3. Mitigation: Apply the patch immediately. If patching is not possible, restrict tag modification permissions to only admin users via policy overrides.

Indicators of Compromise (IOCs)

• Log Entries: Neutron API logs showing update_tags or delete_tags operations on resources where the project_id of the resource does not match the project_id of the authenticated user.
• Network Tags: Unexpected tags on network objects (e.g., networks, subnets, ports) that were not set by the resource owner.
• API Calls: Repeated PUT /v2.0/networks/{id}/tags or DELETE /v2.0/networks/{id}/tags/{tag} requests from a single tenant targeting multiple different network IDs.

Detection Engineering

YARA Rule

rule CVE_2024_53916_Neutron_Tagging_Bypass {
    meta:
        description = "Detects vulnerable Neutron tagging code pattern"
        author = "Valters IT"
        date = "2025-04-17"
        cve = "CVE-2024-53916"
    strings:
        $vuln_pattern = "policy.enforce(context, 'update_tags', resource_type, resource_id=resource_id)"
        $fixed_pattern = "policy.enforce(context, 'update_tags', resource_type, resource_id=resource_id)"
    condition:
        $vuln_pattern and not $fixed_pattern
}

Sigma Rule

title: CVE-2024-53916 - Unauthorized Tag Modification in OpenStack Neutron
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects attempts to modify tags on network resources owned by a different tenant
author: Valters IT
date: 2025-04-17
logsource:
    product: openstack
    service: neutron
detection:
    selection:
        event_type: "update_tags" or "delete_tags"
        resource_type: "network" or "subnet" or "port"
    condition: selection
    filter:
        - user_project_id: resource_project_id
falsepositives:
    - Admin users performing cross-tenant operations
level: medium

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-53916 - OpenStack Neutron Tagging Bypass"; flow:to_server,established; content:"PUT"; http_method; content:"/v2.0/networks/"; http_uri; content:"/tags"; http_uri; pcre:"/\/v2\.0\/networks\/([a-f0-9-]+)\/tags/Ui"; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate: Upgrade Neutron to version 25.0.1, 24.0.2, or 23.2.1 (depending on your release train).
2. Workaround: If patching is not immediately possible, modify the Neutron policy file (policy.json) to restrict tag modification to admin users only:

   {
       "update_tags": "rule:admin_only",
       "delete_tags": "rule:admin_only"
   }
   

3. Monitoring: Enable detailed logging for Neutron API and monitor for unauthorized tag changes.
4. Audit: Review existing tags on network objects for any that appear suspicious or unauthorized.

Valters IT
DevSecOps & Cyber Threat Intelligence