CVE-2024-47825

Executive Summary

CVE-2024-47825 is a medium-severity vulnerability in Cilium, an eBPF-based networking, observability, and security solution. The flaw allows a policy rule denying a prefix broader than /32 to be ignored if a more specific policy rule (CIDRSet or toFQDN) exists that sets enableDefaultDeny: false or toEntities: all. This can lead to unintended network access, bypassing intended security controls. The vulnerability affects Cilium versions 1.14.0 through 1.14.15 and 1.15.0 through 1.15.9. Patches are available in versions 1.14.16 and 1.15.10.

Supply Chain & Package Security

Cilium is distributed as a container image and via Helm charts. Users should verify the integrity of their Cilium images and ensure they are pulling from trusted registries. The vulnerability is in the core policy engine, not in a dependency, so supply chain risk is limited to the Cilium image itself.

CVSS Breakdown & Threat Level

• CVSS Score: 4.0 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: None
• User Interaction: None
• Scope: Unchanged
• Confidentiality Impact: None
• Integrity Impact: Low
• Availability Impact: None

The low EPSS score (0.0%) suggests that exploitation is not currently widespread, but the potential for bypassing network policies makes it a significant concern for organizations relying on Cilium for network segmentation.

Deep Dive & Mechanics

The vulnerability lies in Cilium's policy engine, specifically in how it evaluates egress network policies. When a policy rule denies a broad prefix (e.g., 0.0.0.0/0), it should block all traffic to that range. However, if a more specific rule (e.g., allowing traffic to 10.0.0.0/24) exists and that rule has enableDefaultDeny: false or toEntities: all, the broader deny rule is effectively ignored.

The root cause is a logic error in the policy evaluation code. The engine incorrectly prioritizes the more specific allow rule over the broader deny rule when the specific rule has certain configurations. This bypasses the intended deny-all-except-allow model.

Key Conditions for Exploitation:

1. A policy rule exists that denies a prefix broader than /32 (e.g., 0.0.0.0/0).
2. A more specific policy rule (CIDRSet or toFQDN) exists that allows traffic to a narrower prefix.
3. The specific rule has either enableDefaultDeny: false or toEntities: all.

Vulnerable vs. Patched Code

The vulnerable code is in the policy evaluation logic. The exact fix is not publicly detailed, but it involves correcting the order of operations when evaluating deny vs. allow rules.

Vulnerable Logic (Conceptual):

// Vulnerable: Broader deny is ignored if a specific allow rule exists with certain flags
if specificRule.Allow && (specificRule.EnableDefaultDeny == false || specificRule.ToEntities == "all") {
    // Allow the traffic, ignoring the broader deny
    return Allow
}

Patched Logic (Conceptual):

// Patched: Broader deny is always evaluated first
if broaderRule.Deny {
    return Deny
}
if specificRule.Allow {
    return Allow
}

Exploitation & Lab Setup

Red Team

Prerequisites:

• A Cilium cluster running a vulnerable version (1.14.0-1.14.15 or 1.15.0-1.15.9).
• Ability to create or modify CiliumNetworkPolicy resources.

Exploitation Steps:

1. Create a policy that denies all egress traffic to 0.0.0.0/0.
2. Create a more specific policy that allows traffic to a specific IP (e.g., 10.0.0.1/32) with enableDefaultDeny: false.
3. Traffic to 10.0.0.1 will be allowed, bypassing the broader deny rule.

Example Policy (Vulnerable):

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: deny-all
spec:
  endpointSelector:
    matchLabels:
      app: myapp
  egress:
  - toCIDR:
    - 0.0.0.0/0
    deny: true
---
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-specific
spec:
  endpointSelector:
    matchLabels:
      app: myapp
  egress:
  - toCIDR:
    - 10.0.0.1/32
    enableDefaultDeny: false

Blue Team

Detection:

• Monitor for policy rules with enableDefaultDeny: false or toEntities: all in combination with broader deny rules.
• Use the detection rules below to identify anomalous traffic patterns.

Mitigation:

• Upgrade to Cilium v1.14.16 or v1.15.10.
• Remove enableDefaultDeny: false from policies and explicitly define allow rules.
• Replace toEntities: all with toEntities: world in egress policies.

Indicators of Compromise (IOCs)

• Network Traffic: Unexpected egress traffic to IPs that should be denied by a broader deny rule.
• Policy Audit Logs: Presence of policies with enableDefaultDeny: false or toEntities: all alongside broader deny rules.
• Cilium Agent Logs: Log entries indicating policy evaluation bypasses.

Detection Engineering

YARA Rule

rule CVE_2024_47825_Cilium_Policy_Bypass {
    meta:
        description = "Detects Cilium policy configurations vulnerable to CVE-2024-47825"
        author = "Valters IT"
        date = "2024-10-27"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-47825"
    strings:
        $enableDefaultDeny = "enableDefaultDeny: false"
        $toEntitiesAll = "toEntities: all"
        $denyRule = "deny: true"
    condition:
        ($enableDefaultDeny or $toEntitiesAll) and $denyRule
}

Sigma Rule

title: Cilium Policy Bypass via enableDefaultDeny or toEntities All
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects Cilium policy configurations that may bypass broader deny rules
author: Valters IT
date: 2024-10-27
logsource:
    product: cilium
    service: policy
detection:
    selection:
        - "enableDefaultDeny: false"
        - "toEntities: all"
    condition: selection
falsepositives:
    - Intentional use of these configurations with no broader deny rule
level: medium

Suricata Rule

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-47825 Cilium Policy Bypass - Unexpected Egress"; flow:to_server; content:"|0a|"; depth:1; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Cilium to v1.14.16 or v1.15.10.
2. Review all CiliumNetworkPolicy resources for enableDefaultDeny: false or toEntities: all.
3. Remove enableDefaultDeny: false and explicitly define allow rules.
4. Replace toEntities: all with toEntities: world in egress policies.

Long-Term Measures:

• Implement policy-as-code with automated validation to detect risky configurations.
• Regularly audit Cilium policies for compliance.
• Monitor Cilium security advisories for future patches.

Workarounds (if patching is not immediately possible):

• For policies using enableDefaultDeny: false: Remove this option and explicitly define all allow rules.
• For policies using toEntities: all: Change to toEntities: world.

Valters IT