CVE-2022-1227: Podman Privilege Escalation Vulnerability

CVE-2022-1227 Overview

A privilege escalation vulnerability was discovered in Podman, the popular daemonless container engine for developing, managing, and running OCI Containers. This flaw allows an attacker to publish a malicious image to a public registry. Once this image is downloaded by a potential victim, the vulnerability is triggered after a user runs the podman top command. This action gives the attacker access to the host filesystem, leading to information disclosure or denial of service.

Critical Impact

Attackers can gain unauthorized access to the host filesystem through a malicious container image, enabling data exfiltration or service disruption when users execute the podman top command.

Affected Products

• Podman Project Podman
• PSGo Project PSGo
• Red Hat Enterprise Linux 7.0, 8.0
• Red Hat Enterprise Linux EUS 8.6
• Red Hat OpenShift Container Platform 4.0
• Red Hat Quay 3.0.0
• Red Hat Developer Tools 1.0
• Red Hat Enterprise Linux for IBM z Systems 7.0, 8.6
• Red Hat Enterprise Linux for Power Little Endian 7.0, 8.6
• Red Hat Enterprise Linux Server (various editions)
• Fedora 34, 35

Discovery Timeline

• April 29, 2022 - CVE-2022-1227 published to NVD
• November 21, 2024 - Last updated in NVD database

Technical Details for CVE-2022-1227

Vulnerability Analysis

This vulnerability is classified under CWE-281 (Improper Preservation of Permissions) and CWE-269 (Improper Privilege Management). The flaw exists in how Podman handles process information when executing the podman top command against containers running maliciously crafted images.

The attack requires user interaction—specifically, a victim must download a malicious container image and subsequently execute the podman top command to inspect container processes. This command triggers the vulnerability by improperly handling permissions during process information retrieval, allowing the attacker-controlled code within the container to access the host filesystem.

The vulnerability affects both the Podman container engine and the PSGo library (a Go library for retrieving process information), indicating the root cause may reside in shared process inspection functionality.

Root Cause

The underlying issue stems from improper privilege management during the execution of the podman top command. When this command inspects processes within a container, insufficient permission boundaries allow malicious code embedded in a container image to escape the container's isolation and access the host filesystem. The PSGo library, which Podman uses for process introspection, fails to properly preserve permission constraints during this operation.

Attack Vector

The attack vector is network-based and requires user interaction through the following exploitation chain:

1. Initial Setup: The attacker crafts a malicious container image with embedded code designed to exploit the permission handling flaw
2. Distribution: The malicious image is published to a public container registry (Docker Hub, Quay.io, or similar)
3. Social Engineering: A potential victim downloads the malicious image, potentially through typosquatting, dependency confusion, or impersonating a legitimate image
4. Trigger: When the victim runs podman top <container_id> to inspect processes in the malicious container, the vulnerability is triggered
5. Exploitation: The attacker gains access to the host filesystem, enabling information disclosure or denial of service attacks

The vulnerability mechanism involves the improper handling of process namespaces and filesystem permissions when the podman top command queries process information from a running container. Malicious containers can craft their process information in ways that cause Podman to access host filesystem paths with elevated privileges. For detailed technical information, refer to the GitHub Podman Issue #10941 and Red Hat Bug Report #2070368.

Detection Methods for CVE-2022-1227

Indicators of Compromise

• Unexpected file access or modifications in host filesystem directories from container processes
• Anomalous podman top command executions, especially against recently pulled images from public registries
• Container images from untrusted or unknown sources being pulled and executed
• Unusual process behavior within containers attempting to access /proc or host filesystem paths

Detection Strategies

• Monitor podman top command usage and correlate with recently pulled container images from public registries
• Implement container image scanning to detect suspicious configurations or embedded malicious code before deployment
• Use audit logging to track container runtime operations and filesystem access patterns
• Deploy runtime security monitoring to detect container escape attempts or unauthorized host filesystem access

Monitoring Recommendations

• Enable comprehensive audit logging for all Podman operations, particularly podman top, podman pull, and podman run commands
• Implement alerting for container images pulled from untrusted registries or lacking proper signatures
• Monitor for unusual patterns of filesystem access originating from container processes
• Track and alert on privilege escalation attempts within container environments

How to Mitigate CVE-2022-1227

Immediate Actions Required

• Update Podman to the latest patched version available for your distribution
• Audit currently deployed container images and remove any from untrusted sources
• Restrict usage of podman top command through policy enforcement until patching is complete
• Implement container image signing and verification to prevent execution of untrusted images
• Review and harden container security policies to limit potential impact of container escapes

Patch Information

Security patches are available through distribution-specific package managers. Red Hat has released updates for Enterprise Linux 7.x and 8.x, OpenShift Container Platform, and related products. Fedora has released patches for Fedora 34 and 35. Consult the Fedora Package Announcement for Fedora-specific updates and the Red Hat Bug Report for Red Hat product updates.

Workarounds

• Avoid running podman top against containers from untrusted or unverified image sources
• Implement strict container image policies that only allow images from trusted, verified registries
• Use rootless Podman mode where possible to limit the impact of potential privilege escalation
• Enable SELinux or AppArmor confinement for Podman containers to provide additional isolation layers
• Consider using podman ps with --format options instead of podman top for basic process information

# Configuration example - Restrict container image sources
# /etc/containers/policy.json
{
    "default": [
        {
            "type": "reject"
        }
    ],
    "transports": {
        "docker": {
            "registry.access.redhat.com": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
                }
            ]
        }
    }
}