CVE-2021-41089: Moby Docker Engine Privilege Escalation

CVE-2021-41089 Overview

A file permission vulnerability was discovered in Moby (Docker Engine), the open-source project created by Docker to enable software containerization. The bug affects the docker cp command, where attempting to copy files into a specially-crafted container can result in Unix file permission changes for existing files on the host's filesystem, widening access to others.

Critical Impact

This vulnerability allows attackers to modify file permissions on the host filesystem through a crafted container, potentially enabling unauthorized access when combined with a cooperating process.

Affected Products

• Moby (Docker Engine) versions prior to 20.10.9
• Fedora 34
• Fedora 35

Discovery Timeline

• 2021-10-04 - CVE-2021-41089 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2021-41089

Vulnerability Analysis

This vulnerability is classified under CWE-281 (Improper Preservation of Permissions), which occurs when software fails to properly maintain the correct access permissions during file operations. The flaw manifests in how the docker cp command handles file copying operations when targeting specially-crafted containers.

When docker cp is executed, the underlying archive extraction mechanism creates directories with improper permission handling. Specifically, the issue lies in the pkg/chrootarchive/archive.go file where directory creation occurs outside the expected chroot context. This allows an attacker with the ability to create containers and trigger docker cp operations to manipulate file permissions on the host system.

While this bug does not directly allow files to be read, modified, or executed, it creates a permission widening condition that could be leveraged by an additional cooperating process to gain unauthorized access to sensitive files.

Root Cause

The root cause lies in improper handling of directory creation during the archive extraction process. The original code created directories with ID mapping operations regardless of whether the destination was inside or outside the chroot environment. This lack of distinction allowed permission changes to propagate to the host filesystem when copying files to a root destination.

Attack Vector

The attack requires local access to a system running Docker Engine. An attacker would need to:

1. Create a specially-crafted container designed to exploit the permission handling flaw
2. Trigger a docker cp operation targeting the crafted container
3. Utilize a cooperating process to exploit the widened file permissions on the host

The local attack vector combined with the requirement for an additional cooperating process limits the exploitability, though the potential for privilege escalation in containerized environments makes this a significant security concern.

// Security patch in pkg/chrootarchive/archive.go
// Source: https://github.com/moby/moby/commit/bce32e5c93be4caf1a592582155b9cb837fc129a

 	options.ExcludePatterns = []string{}
 }

-	idMapping := idtools.NewIDMappingsFromMaps(options.UIDMaps, options.GIDMaps)
-	rootIDs := idMapping.RootPair()
+	// If dest is inside a root then directory is created within chroot by extractor.
+	// This case is only currently used by cp.
+	if dest == root {
+		idMapping := idtools.NewIDMappingsFromMaps(options.UIDMaps, options.GIDMaps)
+		rootIDs := idMapping.RootPair()

-	dest = filepath.Clean(dest)
-	if _, err := os.Stat(dest); os.IsNotExist(err) {
-		if err := idtools.MkdirAllAndChownNew(dest, 0755, rootIDs); err != nil {
-			return err
+		dest = filepath.Clean(dest)
+		if _, err := os.Stat(dest); os.IsNotExist(err) {
+			if err := idtools.MkdirAllAndChownNew(dest, 0755, rootIDs); err != nil {
+				return err
+			}
 		}
 	}

Source: GitHub Commit Details

Detection Methods for CVE-2021-41089

Indicators of Compromise

• Unexpected file permission changes on host filesystem files or directories
• Anomalous docker cp commands targeting unusual container paths
• Presence of specially-crafted containers with suspicious directory structures

Detection Strategies

• Monitor docker cp command usage and audit all file copy operations between host and containers
• Implement file integrity monitoring (FIM) on critical host directories to detect permission changes
• Review Docker audit logs for unusual container creation patterns or copy operations
• Deploy container security tools that can detect permission escalation attempts

Monitoring Recommendations

• Enable Docker daemon audit logging and forward logs to a SIEM for analysis
• Set up alerts for permission changes on sensitive host directories
• Monitor for containers with root-level access to host filesystem paths
• Implement runtime container security scanning to detect exploitation attempts

How to Mitigate CVE-2021-41089

Immediate Actions Required

• Update Moby (Docker Engine) to version 20.10.9 or later immediately
• Audit recent docker cp operations for potential exploitation
• Review file permissions on critical host directories for unexpected changes
• Restrict access to the Docker daemon to trusted users only

Patch Information

The vulnerability has been fixed in Moby (Docker Engine) version 20.10.9. The patch modifies the archive extraction logic in pkg/chrootarchive/archive.go to ensure directory creation with ID mapping only occurs when the destination is the same as the root, limiting the scope of permission changes to within the chroot environment.

Users should update to version 20.10.9 or later as soon as possible. Running containers do not need to be restarted after the update. For Fedora users, updated packages are available through the standard package repositories.

Additional security advisories and patch details are available from:

• GitHub Security Advisory
• Siemens Security Advisory

Workarounds

• Restrict docker cp usage to trusted administrators only until the patch is applied
• Implement strict access controls on the Docker daemon socket
• Use read-only container filesystems where possible to limit potential attack surface
• Consider implementing AppArmor or SELinux profiles to restrict Docker operations

# Configuration example
# Verify Docker Engine version after update
docker version --format '{{.Server.Version}}'

# Restrict Docker socket access to authorized users
sudo chmod 660 /var/run/docker.sock
sudo chown root:docker /var/run/docker.sock

# Audit docker cp operations (add to Docker daemon audit rules)
# Add to /etc/audit/rules.d/docker.rules
-a always,exit -F path=/usr/bin/docker -F perm=x -k docker_commands