CVE-2022-27649: Podman Privilege Escalation Vulnerability

CVE-2022-27649 Overview

A flaw was found in Podman, where containers were started incorrectly with non-empty default permissions. This vulnerability affects how Linux process capabilities are inherited during container execution. The flaw allows an attacker with access to programs with inheritable file capabilities to elevate those capabilities to the permitted set when execve(2) runs, potentially leading to privilege escalation within the container environment.

Critical Impact

Attackers with access to programs containing inheritable file capabilities can escalate privileges within containers, potentially compromising container isolation and gaining elevated access to system resources.

Affected Products

• Podman Project Podman
• Red Hat Enterprise Linux 8.x (including EUS variants)
• Red Hat OpenShift Container Platform 4.0
• Red Hat Developer Tools 1.0
• Fedora 34, 35, and 36
• Red Hat Enterprise Linux for IBM z Systems 8.x
• Red Hat Enterprise Linux for Power (little endian) 8.x

Discovery Timeline

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

Technical Details for CVE-2022-27649

Vulnerability Analysis

This vulnerability stems from improper default permissions assigned to containers during startup. In Linux, process capabilities are divided into several sets: permitted, effective, inheritable, bounding, and ambient. The inheritable capability set determines which capabilities can be inherited across execve(2) calls when combined with file capabilities.

Podman was incorrectly configuring containers with non-empty inheritable capability sets, which violates the principle of least privilege. When a containerized process executes a binary that has inheritable file capabilities set, those capabilities are added to the permitted capability set of the new process. This creates a privilege escalation vector where an attacker can gain capabilities they should not possess.

The vulnerability is particularly dangerous in multi-tenant container environments where users may have limited privileges but can still execute binaries within containers. The network-based attack vector with high complexity indicates that exploitation requires specific conditions but can be performed remotely in certain configurations.

Root Cause

The root cause is CWE-276 (Incorrect Default Permissions). Podman failed to properly clear the inheritable capability set when starting containers, deviating from the expected behavior where the Linux kernel clears inheritable capabilities by default. This oversight allowed capabilities to propagate inappropriately through execve(2) calls.

Attack Vector

The attack requires low-privilege access to a running container environment. An attacker must have access to or be able to place a binary with inheritable file capabilities within the container. When this binary is executed, the misconfigured inheritable capabilities from the container process combine with the file's inheritable capabilities, elevating the permitted capability set of the resulting process.

// Security patch in libpod/oci_conmon_exec_linux.go - do not set the inheritable capabilities
 	} else {
 		pspec.Capabilities.Bounding = ctrSpec.Process.Capabilities.Bounding
 	}

+	// Always unset the inheritable capabilities similarly to what the Linux kernel does
+	// They are used only when using capabilities with uid != 0.
+	pspec.Capabilities.Inheritable = []string{}
+
 	if execUser.Uid == 0 {
 		pspec.Capabilities.Effective = pspec.Capabilities.Bounding
-		pspec.Capabilities.Inheritable = pspec.Capabilities.Bounding
 		pspec.Capabilities.Permitted = pspec.Capabilities.Bounding
-		pspec.Capabilities.Ambient = pspec.Capabilities.Bounding
 	} else {
 		if user == c.config.User {
 			pspec.Capabilities.Effective = ctrSpec.Process.Capabilities.Effective

Source: GitHub Podman Commit

Detection Methods for CVE-2022-27649

Indicators of Compromise

• Unexpected capability escalation events logged by container runtime or audit subsystem
• Processes within containers showing elevated capabilities in /proc/[pid]/status (CapInh, CapPrm, CapEff fields)
• Anomalous execution of binaries with file capabilities set within container environments
• Audit logs showing execve(2) calls resulting in capability transitions

Detection Strategies

• Monitor container process capabilities using tools like capsh --print or parsing /proc/[pid]/status for unexpected CapInh values
• Implement audit rules to track execve(2) syscalls within container namespaces that result in capability changes
• Deploy runtime security tools to detect privilege escalation attempts within container boundaries
• Review container images for binaries with inheritable file capabilities using getcap -r /

Monitoring Recommendations

• Enable container runtime audit logging to capture capability-related events
• Configure SentinelOne Singularity Cloud Workload Security to monitor for container escape and privilege escalation patterns
• Implement network segmentation monitoring for containerized workloads to detect lateral movement following potential exploitation
• Set up alerts for processes executing with unexpected capability combinations within container namespaces

How to Mitigate CVE-2022-27649

Immediate Actions Required

• Update Podman to the latest patched version immediately on all affected systems
• Review running containers for any signs of compromise or unexpected capability configurations
• Audit container images for binaries with inheritable file capabilities that could be exploited
• Apply Red Hat security advisories for affected Enterprise Linux and OpenShift platforms

Patch Information

The vulnerability has been addressed in the Podman project through commit aafa80918a245edcbdaceb1191d749570f1872d0. The fix ensures that inheritable capabilities are always set to an empty list, mimicking the default Linux kernel behavior. Updated packages are available through:

• Red Hat Bug Report
• GitHub Security Advisory GHSA-qvf8-p83w-v58j
• Fedora Package Announcements for Fedora 34, 35, and 36

Workarounds

• Manually clear inheritable capabilities when launching containers using custom seccomp profiles or capability drop options
• Remove or strip file capabilities from binaries within container images using setcap -r command
• Run containers with --cap-drop=all and explicitly add only required capabilities to minimize attack surface
• Implement Pod Security Policies or Pod Security Standards in Kubernetes/OpenShift to restrict capability usage

# Configuration example - Drop all capabilities and add only required ones
podman run --cap-drop=all --cap-add=NET_BIND_SERVICE your-container-image

# Remove file capabilities from a binary inside a container
setcap -r /path/to/binary

# Verify no inheritable capabilities are set on a binary
getcap /path/to/binary