CVE-2024-42480

Executive Summary

CVE-2024-42480 is a critical privilege escalation vulnerability in Kamaji, the Hosted Control Plane Manager for Kubernetes. The flaw resides in the RBAC (Role-Based Access Control) configuration for etcd roles, where an overly permissive range definition allows one tenant's Kubernetes API server to read, write, and delete the etcd data of other tenants' control planes. This effectively breaks multi-tenancy isolation, enabling a compromised or malicious tenant to access, modify, or destroy the state of other hosted clusters. The vulnerability affects all versions up to and including 1.0.0. A fix is available in the edge-24.8.2 release, but no official stable patch has been published.

Supply Chain & Package Security

Kamaji is a Go-based project distributed as a container image and via GitHub releases. The vulnerability is in the core control plane logic, not in a package dependency. However, users should verify the integrity of the Kamaji binary or container image they deploy, as the fix is only available in an edge release. The project does not have a signed SBOM or provenance attestation for the edge release, increasing supply chain risk for early adopters of the patch.

CVSS Breakdown & Threat Level

CVSS Score: 8.1 (High) Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

• Attack Vector (AV): Network – The vulnerability can be exploited remotely over the network.
• Attack Complexity (AC): Low – No special conditions or race conditions required.
• Privileges Required (PR): None – An attacker does not need any prior authentication.
• User Interaction (UI): None – No user action is needed.
• Scope (S): Unchanged – The vulnerable component and the impacted component are the same.
• Confidentiality (C): High – Full read access to all etcd data of other tenants.
• Integrity (I): High – Full write/delete access to all etcd data of other tenants.
• Availability (A): High – Ability to delete critical cluster state, causing denial of service.

Threat Level: Critical – The vulnerability allows complete compromise of multi-tenant isolation, leading to data breach, cluster takeover, and denial of service.

Deep Dive & Mechanics

Kamaji manages hosted control planes by running a dedicated etcd instance for each tenant. The etcd roles are defined with RBAC rules to restrict access. The vulnerability stems from an overly permissive range definition in the RBAC configuration for etcd roles. Specifically, the range is defined as "open at the top," meaning that the RBAC rule does not properly limit the key space that a tenant's API server can access. This allows a tenant's API server to read, write, and delete keys belonging to other tenants' control planes.

The affected code is in the RBAC configuration generation for etcd roles. The range definition likely uses a prefix that is too broad or lacks a proper upper bound. For example, a rule might allow access to keys starting with /registry/ without restricting it to the tenant's specific namespace, such as /registry/tenants/<tenant-id>/. This allows a malicious API server to access /registry/tenants/<other-tenant-id>/ as well.

The fix in edge-24.8.2 tightens the range definition to be scoped to the specific tenant's key space, ensuring that each API server can only access its own etcd data.

Vulnerable vs. Patched Code

The exact code change is not publicly available, but based on the advisory, the vulnerable code likely looks like this:

Vulnerable (<= 1.0.0):

// etcdRole returns an etcd role with overly permissive range
func etcdRole(tenantID string) *etcd.Role {
    return &etcd.Role{
        Name: "tenant-" + tenantID,
        KeyRange: &etcd.KeyRange{
            Start: []byte("/registry/"),
            End:   []byte{0}, // "open at the top" - allows access to all keys starting with /registry/
        },
        ReadWrite: true,
    }
}

Patched (edge-24.8.2):

// etcdRole returns an etcd role with scoped range
func etcdRole(tenantID string) *etcd.Role {
    return &etcd.Role{
        Name: "tenant-" + tenantID,
        KeyRange: &etcd.KeyRange{
            Start: []byte("/registry/tenants/" + tenantID + "/"),
            End:   []byte("/registry/tenants/" + tenantID + "0"), // properly bounded
        },
        ReadWrite: true,
    }
}

The patched version uses a specific prefix for the tenant's key space and a proper upper bound to prevent access to other tenants' keys.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Access to a Kamaji-managed Kubernetes cluster with at least two tenants.
• Ability to deploy a custom API server or modify an existing tenant's API server configuration.

Exploitation Steps:

1. Identify the etcd endpoint for your tenant's control plane (usually exposed via a service).
2. Deploy a malicious API server that connects to the etcd endpoint using the same credentials as your legitimate API server.
3. Use the etcd client to list keys under /registry/:

   ETCDCTL_API=3 etcdctl --endpoints=<etcd-endpoint> get /registry/ --prefix --keys-only
   

4. If successful, you will see keys from other tenants, e.g., /registry/tenants/other-tenant/pods/malicious-pod.
5. Read, write, or delete keys to compromise other tenants:

   # Read a pod definition from another tenant
   etcdctl get /registry/tenants/other-tenant/pods/legitimate-pod
   # Delete a critical resource
   etcdctl del /registry/tenants/other-tenant/deployments/critical-app
   

Expected Outcome: Full control over other tenants' control plane state.

Blue Team

Detection:

• Monitor etcd access logs for requests to key prefixes outside the expected tenant scope.
• Alert on etcd operations that use a broad range (e.g., /registry/ without a tenant-specific prefix).
• Use network segmentation to restrict API server to etcd communication to only the expected key space.

Hunting:

• Query etcd audit logs for range requests with a start key of /registry/ and an end key of \x00 (null byte).
• Look for API servers that are making requests to keys belonging to other tenants.

Mitigation:

• Immediately upgrade to edge-24.8.2 or apply the manual RBAC fix.
• If upgrade is not possible, implement a network policy that restricts each API server's etcd access to only its own key space using a sidecar proxy or eBPF.

Indicators of Compromise (IOCs)

• Network: Unusual etcd traffic from an API server to keys outside its tenant prefix.
• Logs: etcd audit logs showing range requests with key starting with /registry/ and range_end set to \x00.
• File System: Modified etcd data for other tenants (e.g., unexpected changes to pod definitions, secrets, or deployments).
• Process: Anomalous API server processes making direct etcd calls without going through the Kamaji controller.

Detection Engineering

YARA Rule

rule CVE_2024_42480_Kamaji_Etcd_RBAC {
    meta:
        description = "Detects overly permissive etcd RBAC range definition in Kamaji source code"
        author = "Valters IT"
        date = "2024-08-20"
        reference = "CVE-2024-42480"
        severity = "critical"
    strings:
        $vuln_range = /KeyRange\s*:\s*&etcd\.KeyRange\s*\{\s*Start:\s*\[\]byte\(\"\/registry\/\"\)\s*,\s*End:\s*\[\]byte\{0\}\s*\}/
    condition:
        $vuln_range
}

Sigma Rule

title: CVE-2024-42480 - Kamaji etcd RBAC Overly Permissive Range
id: 8a4b3c2d-1e5f-4a7b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects etcd audit log entries indicating a broad key range request that may indicate exploitation of CVE-2024-42480
author: Valters IT
date: 2024-08-20
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-42480
logsource:
    product: etcd
    service: audit
detection:
    selection:
        request.key|startswith: "/registry/"
        request.range_end: "\x00"
    condition: selection
falsepositives:
    - Legitimate Kamaji operations if the fix is not applied (but this is the vulnerable behavior)
level: critical

Suricata Rule

alert tcp any any -> any 2379 (msg:"CVE-2024-42480 - Kamaji etcd Broad Key Range Request"; content:"/registry/"; depth:10; content:"|00|"; within:2; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade to Kamaji edge-24.8.2 or later.
2. If upgrade is not possible, manually patch the RBAC configuration for etcd roles to use a scoped key range per tenant.
3. Restrict network access between API servers and etcd to only the necessary key space using a sidecar proxy (e.g., Envoy) with RBAC enforcement.

Long-Term Fixes:

• Implement a formal RBAC review process for all etcd role definitions.
• Add unit tests to verify that each tenant's API server cannot access other tenants' keys.
• Use a dedicated etcd instance per tenant (if not already done) to provide stronger isolation.

Workarounds:

• Deploy a webhook or admission controller that validates the etcd RBAC configuration before it is applied.
• Monitor etcd audit logs for any suspicious range requests and alert immediately.

Valters IT