CVE-2022-24769: Moby Privilege Escalation Vulnerability

CVE-2022-24769 Overview

A privilege escalation vulnerability was discovered in Moby (Docker Engine) prior to version 20.10.14 where containers were incorrectly started with non-empty inheritable Linux process capabilities. This creates an atypical Linux environment that enables programs with inheritable file capabilities to elevate those capabilities to the permitted set during execve(2) system calls, potentially allowing unprivileged users within containers to gain elevated privileges.

Critical Impact

Containers with executable programs possessing inheritable file capabilities allow unprivileged users and processes to gain additional inheritable capabilities up to the container's bounding set, particularly impacting containers that use Linux users and groups for privilege separation.

Affected Products

• Moby Project Moby (Docker Engine) versions prior to 20.10.14
• Linux Foundation runc (affected versions)
• Fedora 34, 35, and 36
• Debian Linux 11.0

Discovery Timeline

• 2022-03-24 - CVE CVE-2022-24769 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2022-24769

Vulnerability Analysis

This vulnerability stems from improper permission assignment for critical resources (CWE-732) within the Docker Engine's container initialization process. When containers are started, the Docker Engine configures Linux capabilities sets that control what privileged operations processes can perform. Due to this bug, the inheritable capability set was incorrectly populated with capabilities during container startup.

In standard Linux environments, when executable programs have specified permitted file capabilities, unprivileged users can execute those programs and gain the specified file capabilities up to the bounding set. The vulnerability extends this behavior by allowing processes to additionally gain inheritable file capabilities up to the container's bounding set during execve(2) calls.

Importantly, this vulnerability does not affect the container security sandbox itself, as the inheritable set never contained more capabilities than were included in the container's bounding set. However, containers utilizing Linux users and groups for internal privilege separation are most directly impacted, as the atypical capability environment could allow privilege escalation within the container.

Root Cause

The root cause lies in how Moby configured the specs.LinuxCapabilities structure during container initialization. The Docker Engine was incorrectly setting the Inheritable capability set alongside Bounding, Permitted, and Effective sets. In a proper Linux security model, the inheritable set should typically be empty for non-privileged containers to prevent capability inheritance across execve(2) boundaries.

The fix removes the assignment of inheritable capabilities from both privileged container execution (daemon/exec_linux.go) and default container specifications (oci/defaults.go), ensuring containers start with an empty inheritable capability set consistent with standard Linux behavior.

Attack Vector

The attack requires local access to a container environment. An attacker with access to an unprivileged user account inside a vulnerable container could:

1. Identify executable programs within the container that have inheritable file capabilities set
2. Execute these programs to inherit capabilities into their permitted set
3. Leverage the elevated capabilities to perform privileged operations within the container
4. Potentially escalate privileges to compromise container-level access controls

The following patch demonstrates the fix implemented in daemon/exec_linux.go:

 		}
 	}
 	if ec.Privileged {
-		if p.Capabilities == nil {
-			p.Capabilities = &specs.LinuxCapabilities{}
+		p.Capabilities = &specs.LinuxCapabilities{
+			Bounding:  caps.GetAllCapabilities(),
+			Permitted: caps.GetAllCapabilities(),
+			Effective: caps.GetAllCapabilities(),
 		}
-		p.Capabilities.Bounding = caps.GetAllCapabilities()
-		p.Capabilities.Permitted = p.Capabilities.Bounding
-		p.Capabilities.Inheritable = p.Capabilities.Bounding
-		p.Capabilities.Effective = p.Capabilities.Bounding
 	}
 	if apparmor.HostSupports() {
 		var appArmorProfile string

Source: GitHub Moby Commit Update

The corresponding fix in oci/defaults.go similarly removes the inheritable capability assignment:

 	Version: specs.Version,
 	Process: &specs.Process{
 		Capabilities: &specs.LinuxCapabilities{
-			Bounding:    caps.DefaultCapabilities(),
-			Permitted:   caps.DefaultCapabilities(),
-			Inheritable: caps.DefaultCapabilities(),
-			Effective:   caps.DefaultCapabilities(),
+			Bounding:  caps.DefaultCapabilities(),
+			Permitted: caps.DefaultCapabilities(),
+			Effective: caps.DefaultCapabilities(),
 		},
 	},
 	Root: &specs.Root{},

Source: GitHub Moby Commit Update

Detection Methods for CVE-2022-24769

Indicators of Compromise

• Unusual capability elevation patterns within container processes during execve(2) calls
• Container processes operating with unexpected inheritable capabilities in /proc/[pid]/status
• Abnormal privilege escalation attempts within containers using Linux user/group separation
• Processes gaining file capabilities beyond expected permission boundaries

Detection Strategies

• Monitor container runtime logs for capability-related anomalies during process execution
• Implement audit rules to track execve(2) system calls within containers and flag capability inheritance
• Use container security tools to scan for binaries with inheritable file capabilities set
• Deploy runtime security solutions to detect privilege escalation attempts within container environments

Monitoring Recommendations

• Enable detailed Docker Engine logging to capture container initialization and capability assignment
• Implement process monitoring within containers to detect capability changes during execution
• Configure alerting for any processes acquiring capabilities beyond their initial assignment
• Review container images for executables with inheritable file capabilities using tools like getcap

How to Mitigate CVE-2022-24769

Immediate Actions Required

• Upgrade Moby (Docker Engine) to version 20.10.14 or later immediately
• Stop, delete, and recreate all running containers to reset inheritable capabilities
• Audit container images for executables with inheritable file capabilities
• Review containers using Linux user/group privilege separation for potential exposure

Patch Information

The vulnerability has been fixed in Moby (Docker Engine) version 20.10.14. The fix changes Docker Engine behavior to start containers with a more typical Linux environment where the inheritable capability set is empty. Security updates are also available through distribution channels for Fedora, Debian, and Gentoo Linux.

Key resources for patching:

• GitHub Moby Release v20.10.14
• GitHub Security Advisory GHSA-2mm7-x5h6-5pvq
• Debian Security Advisory DSA-5162
• Gentoo GLSA 202401-31

Workarounds

• Modify container entry points to use capsh(1) utility to drop inheritable capabilities before starting the primary process
• Avoid running executables with inheritable file capabilities in affected containers
• Implement strict capability dropping in container initialization scripts
• Consider using seccomp profiles to limit capability-related system calls

# Configuration example - Drop inheritable capabilities using capsh
# Modify container entrypoint to include capability dropping
docker run --entrypoint="/bin/sh" myimage -c \
  "capsh --inh='' --drop=all -- -c '/app/entrypoint.sh'"

# Alternatively, create a wrapper script for container entry
#!/bin/bash
# /usr/local/bin/secure-entrypoint.sh
exec capsh --inh='' -- -c "$@"