CVE-2024-3154: CRI-O Container RCE Vulnerability

CVE-2024-3154 Overview

A command injection vulnerability was discovered in CRI-O, a lightweight container runtime for Kubernetes. The flaw allows arbitrary systemd property injection via Pod annotations, enabling any user who can create a pod with arbitrary annotations to perform unauthorized actions on the host system. This vulnerability affects the core container runtime used in Kubernetes environments, potentially allowing attackers to escape container isolation and compromise the underlying host.

Critical Impact

Attackers with pod creation privileges can inject arbitrary systemd properties through Pod annotations, leading to potential container escape and full host system compromise in Kubernetes environments.

Affected Products

• CRI-O container runtime (vulnerable versions prior to security patches)
• Red Hat OpenShift Container Platform
• Kubernetes clusters utilizing CRI-O as the container runtime

Discovery Timeline

• April 26, 2024 - CVE CVE-2024-3154 published to NVD
• November 21, 2024 - Last updated in NVD database

Technical Details for CVE-2024-3154

Vulnerability Analysis

This vulnerability is classified as CWE-77 (Command Injection), where an attacker can inject arbitrary systemd properties through Kubernetes Pod annotations. CRI-O, the container runtime, processes these annotations without adequate validation, allowing malicious systemd unit properties to be passed to the underlying host system's init daemon.

The attack requires network access and high privileges (the ability to create pods with custom annotations). However, once exploited, the impact is severe as it allows complete compromise of confidentiality, integrity, and availability of the host system. The vulnerability enables attackers to break out of container isolation boundaries, a critical security control in Kubernetes environments.

Root Cause

The root cause lies in insufficient input validation and sanitization of Pod annotation values before they are processed by CRI-O and passed to systemd. CRI-O allows certain annotations to configure systemd properties for containers, but the implementation failed to properly restrict which properties could be set. This allows attackers to inject dangerous systemd properties that execute arbitrary commands or modify system configurations at the host level.

The vulnerability relates to unsafe annotation handling as documented in the OCI runtime specification, where annotations passed through to runc can have security implications if not properly validated.

Attack Vector

The attack is network-accessible and requires an attacker to have privileges to create Kubernetes pods with custom annotations. The attacker crafts a malicious Pod specification containing specially crafted annotations that, when processed by CRI-O, inject arbitrary systemd unit properties. These properties are then executed by systemd on the host, allowing the attacker to execute commands, modify files, or perform other actions with root-level host system privileges.

The attack flow involves:

1. Creating a Pod manifest with malicious annotations targeting systemd properties
2. CRI-O processing the Pod specification without adequate validation
3. Malicious systemd properties being applied to the container's systemd unit
4. Arbitrary command execution or system modification occurring on the host

Since no verified code examples are available for this vulnerability, refer to the GitHub Advisory GHSA-2cgq-h8xw-2v5j for detailed technical information about the exploitation mechanism.

Detection Methods for CVE-2024-3154

Indicators of Compromise

• Unusual Pod annotations containing systemd property syntax (e.g., ExecStart=, ExecStartPre=, or other systemd unit directives)
• Unexpected systemd unit modifications or service creations on Kubernetes worker nodes
• Suspicious processes spawned by systemd that correlate with container creation events
• Anomalous file system changes on host systems during or after pod deployments

Detection Strategies

• Monitor Kubernetes audit logs for Pod creation events with suspicious or overly permissive annotations
• Implement admission controllers (OPA Gatekeeper, Kyverno) to validate and restrict allowed Pod annotations
• Enable SentinelOne Kubernetes workload protection to detect container escape attempts and suspicious host-level activities
• Review systemd journal logs for unexpected unit property changes correlating with container lifecycle events

Monitoring Recommendations

• Configure SentinelOne to monitor for unexpected process spawning from container runtime contexts
• Set up alerts for Pod creation events with non-standard or untrusted annotations
• Monitor for privilege escalation patterns from container processes to host-level execution
• Track systemd unit changes and correlate with Kubernetes deployment activities

How to Mitigate CVE-2024-3154

Immediate Actions Required

• Update CRI-O to the latest patched version immediately on all Kubernetes worker nodes
• Apply the security patches referenced in the Red Hat security advisories (RHSA-2024:2669, RHSA-2024:2672, RHSA-2024:2784, RHSA-2024:3496)
• Review and restrict RBAC policies to limit which users can create Pods with arbitrary annotations
• Implement admission controllers to validate and restrict Pod annotations to a known-safe list

Patch Information

Red Hat has released multiple security advisories addressing this vulnerability across their OpenShift Container Platform products:

• RHSA-2024:2669 - Security update for CRI-O
• RHSA-2024:2672 - Security update for CRI-O
• RHSA-2024:2784 - Security update for CRI-O
• RHSA-2024:3496 - Security update for CRI-O

For additional details, refer to the Red Hat CVE Report and the GitHub security advisory.

Workarounds

• Implement strict Pod Security Standards (PSS) to restrict the use of potentially dangerous annotations
• Use admission webhooks to deny pods with suspicious annotation patterns
• Limit pod creation privileges using Kubernetes RBAC to trusted users only
• Consider temporarily restricting annotation capabilities via OPA Gatekeeper policies until patches can be applied

# Example: Kyverno policy to restrict dangerous annotations
# Save as restrict-pod-annotations.yaml and apply to cluster
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-pod-annotations
spec:
  validationFailureAction: enforce
  rules:
  - name: block-dangerous-annotations
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "Pod annotations with systemd properties are not allowed"
      pattern:
        metadata:
          annotations:
            "!io.kubernetes.cri-o.*": "*"