CVE-2021-21284: Docker Privilege Escalation Vulnerability

CVE-2021-21284 Overview

CVE-2021-21284 is a privilege escalation vulnerability in Docker that affects the --userns-remap feature. When user namespace remapping is enabled, the root user within the remapped namespace can escalate privileges to the actual host root if they have access to the host filesystem. This occurs because an attacker with access to the remapped root can modify files under /var/lib/docker/<remapping> that cause writing files with extended privileges, effectively bypassing the container isolation that user namespace remapping is designed to provide.

Critical Impact

Attackers with remapped root access can escalate to real host root privileges by manipulating files in the Docker data directory, completely undermining the security boundaries of user namespace remapping.

Affected Products

• Docker versions prior to 19.03.15
• Docker versions prior to 20.10.3
• Debian Linux 10.0
• NetApp E-Series SANtricity OS Controller

Discovery Timeline

• 2021-02-02 - CVE-2021-21284 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2021-21284

Vulnerability Analysis

This vulnerability is classified as CWE-22 (Path Traversal) and involves improper permission handling in Docker's user namespace remapping implementation. The --userns-remap feature is designed to run container processes as a non-privileged user on the host system, even when they appear to run as root inside the container. However, a flaw in how Docker set directory permissions allowed a remapped root user to traverse and modify files in /var/lib/docker/<remapping>, enabling them to write files with elevated privileges.

The vulnerability requires adjacent network access and low privileges to exploit, with no user interaction necessary. The primary impact is on integrity, as successful exploitation allows unauthorized file modifications that lead to privilege escalation beyond the intended container boundaries.

Root Cause

The root cause lies in how Docker created and set permissions on container-related directories. The daemon used daemon.idMapping.RootPair() to set ownership of critical directories like the container root and checkpoint directories, combined with restrictive 0700 permissions. This allowed the remapped root user to own and access these directories, enabling them to modify files that would later be interpreted with host root privileges.

The fix changed the ownership model to use idtools.CurrentIdentity() (the actual daemon user identity) instead of the remapped root pair, and adjusted permissions to 0701 where appropriate, ensuring that the remapped user cannot modify sensitive Docker daemon files.

Attack Vector

The attack requires the following conditions:

1. Docker configured with --userns-remap option enabled
2. An attacker with root access within a container using user namespace remapping
3. Some form of access to the host filesystem (e.g., through volume mounts or container escape)

Once these conditions are met, the attacker can manipulate files under the Docker data directory to write files with extended host privileges, effectively escaping the user namespace isolation.

// Security patch in daemon/container_operations_unix.go
// Before: Directory owned by remapped root pair
// After: Directory owned by current daemon identity

 	if err != nil {
 		return err
 	}
-	return idtools.MkdirAllAndChown(p, 0700, daemon.idMapping.RootPair())
+	return idtools.MkdirAllAndChown(p, 0701, idtools.CurrentIdentity())
}

Source: Moby GitHub Commit

// Security patch in daemon/create.go
// Changed ownership from remapped root to current identity

 	}
 	ctr.RWLayer = rwLayer

-	rootIDs := daemon.idMapping.RootPair()
-
-	if err := idtools.MkdirAndChown(ctr.Root, 0700, rootIDs); err != nil {
+	if err := idtools.MkdirAndChown(ctr.Root, 0701, idtools.CurrentIdentity()); err != nil {
 		return nil, err
 	}
-	if err := idtools.MkdirAndChown(ctr.CheckpointDir(), 0700, rootIDs); err != nil {
+	if err := idtools.MkdirAndChown(ctr.CheckpointDir(), 0700, idtools.CurrentIdentity()); err != nil {
 		return nil, err
 	}

Source: Moby GitHub Commit

Detection Methods for CVE-2021-21284

Indicators of Compromise

• Unexpected file ownership changes under /var/lib/docker/ directories
• Files created with elevated privileges originating from container processes
• Unusual write activity in Docker remapping directories by container users
• Container processes accessing or modifying files outside expected volume mounts

Detection Strategies

• Monitor file system activity in /var/lib/docker/<remapping> directories for unauthorized modifications
• Audit Docker daemon logs for containers running with --userns-remap that access sensitive host paths
• Deploy runtime container security tools that detect privilege escalation attempts
• Implement file integrity monitoring (FIM) on Docker data directories

Monitoring Recommendations

• Enable Docker daemon audit logging to track container file system operations
• Configure alerts for any container process attempting to write to /var/lib/docker/ paths
• Use SentinelOne's container runtime protection to detect real-time privilege escalation behaviors
• Monitor for processes running as the remapped UID that access files owned by actual root

How to Mitigate CVE-2021-21284

Immediate Actions Required

• Upgrade Docker to version 20.10.3 or 19.03.15 immediately
• Audit all running containers using --userns-remap for potential compromise
• Review and restrict volume mounts that provide container access to host filesystem paths
• Temporarily disable --userns-remap if patching cannot be performed immediately

Patch Information

Docker has released patched versions that address this vulnerability by changing how directory ownership and permissions are set during container creation:

• Docker 20.10.3: Contains the security fix for this vulnerability (Docker Release Notes)
• Docker 19.03.15: Backported fix for the 19.03 release branch (Moby Release v19.03.15)

The patch modifies the daemon to use idtools.CurrentIdentity() instead of daemon.idMapping.RootPair() when setting ownership on container directories, ensuring that the remapped root user cannot manipulate these files. Additional security advisories have been issued by Debian (DSA-4865), Gentoo (GLSA 202107-23), and NetApp (NTAP-20210226-0005).

Workarounds

• Disable --userns-remap feature if not strictly required for your deployment
• Restrict container access to the host filesystem by avoiding bind mounts to sensitive directories
• Run containers with --read-only filesystem where possible to prevent write operations
• Implement strict AppArmor or SELinux profiles to limit container file system access

# Check current Docker version
docker version --format '{{.Server.Version}}'

# Verify if userns-remap is enabled
docker info --format '{{.SecurityOptions}}'

# Upgrade Docker on Debian/Ubuntu
sudo apt-get update && sudo apt-get install docker-ce=5:20.10.3~3-0~ubuntu-focal

# Disable userns-remap temporarily (restart required)
# Remove --userns-remap from /etc/docker/daemon.json or daemon startup flags
sudo systemctl restart docker