CVE-2020-15257: Containerd Privilege Escalation Vulnerability

CVE-2020-15257 Overview

CVE-2020-15257 is a privilege escalation vulnerability in containerd, an industry-standard container runtime available as a daemon for Linux and Windows. The vulnerability stems from improper exposure of the containerd-shim API to host network containers, allowing malicious containers to execute new processes with elevated privileges.

Critical Impact

Malicious containers running in the same network namespace as the shim with an effective UID of 0 can cause new processes to be run with elevated privileges, potentially leading to container escape and host compromise.

Affected Products

• Linux Foundation containerd versions before 1.3.9
• Linux Foundation containerd versions before 1.4.3
• Fedora 33
• Debian Linux 10.0

Discovery Timeline

• 2020-12-01 - CVE-2020-15257 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2020-15257

Vulnerability Analysis

The vulnerability exists in the containerd-shim API's access control mechanism. While the shim's API socket correctly verifies that connecting processes have an effective UID of 0, it fails to implement additional access restrictions to the abstract Unix domain socket. This insufficient access control allows containers sharing the same network namespace as the shim to interact with the API despite having otherwise reduced privileges.

The attack surface is particularly concerning in configurations where containers run with --net=host (Docker) or hostNetwork: true (Kubernetes), as these settings place containers in the same network namespace as the containerd-shim. The CWE-669 (Incorrect Resource Transfer Between Spheres) classification highlights that the vulnerability involves improper resource access boundaries between the container and host environments.

Root Cause

The root cause is the use of abstract Unix domain sockets for the containerd-shim API without proper namespace isolation. Abstract sockets in Linux are accessible to any process in the same network namespace, regardless of other containerization mechanisms. The access control only checked for UID 0 but did not verify that the connecting process was actually authorized to communicate with the shim.

Attack Vector

The attack requires local access and involves a container configured with host network namespace access running as root (UID 0). An attacker controlling such a container can:

1. Connect to the containerd-shim's abstract Unix domain socket
2. Leverage the shim API to spawn new processes with elevated privileges
3. Potentially escape the container's isolation boundaries

The following patch shows the fix applied to address this vulnerability, changing from abstract socket paths to filesystem-based socket paths:

 func init() {
 	flag.BoolVar(&debugFlag, "debug", false, "enable debug output in logs")
 	flag.StringVar(&namespaceFlag, "namespace", "", "namespace that owns the shim")
-	flag.StringVar(&socketFlag, "socket", "", "abstract socket path to serve")
+	flag.StringVar(&socketFlag, "socket", "", "socket path to serve")
 	flag.StringVar(&addressFlag, "address", "", "grpc address back to main containerd")
 	flag.StringVar(&workdirFlag, "workdir", "", "path used to storge large temporary data")
 	flag.StringVar(&runtimeRootFlag, "runtime-root", process.RuncRoot, "root directory for the runtime")

Source: GitHub Commit Details

Detection Methods for CVE-2020-15257

Indicators of Compromise

• Unexpected processes spawned from containers running with host network namespace
• Unauthorized connections to containerd-shim Unix domain sockets from container processes
• Evidence of privilege escalation attempts within container environments

Detection Strategies

• Monitor for containers running with --net=host or hostNetwork: true configurations, especially those running as root
• Audit containerd-shim socket activity for anomalous connection patterns
• Implement runtime security monitoring to detect unauthorized process creation from container contexts
• Review container orchestration configurations for unnecessary host namespace sharing

Monitoring Recommendations

• Enable containerd debug logging to capture shim API access attempts
• Deploy container runtime security solutions to monitor for privilege escalation behaviors
• Implement network namespace auditing to identify containers with excessive host access
• Configure alerts for containers attempting to access abstract Unix domain sockets

How to Mitigate CVE-2020-15257

Immediate Actions Required

• Upgrade containerd to version 1.3.9 or 1.4.3 or later immediately
• Stop and restart all containers that were started with vulnerable containerd-shim versions, as running containers remain vulnerable even after upgrading
• Review and remove unnecessary --net=host or hostNetwork: true configurations from container deployments
• Ensure containers run with non-zero UIDs where possible

Patch Information

The vulnerability has been fixed in containerd versions 1.3.9 and 1.4.3. The fix changes the shim API socket from an abstract Unix domain socket to a filesystem-based socket, which provides proper isolation through filesystem permissions. Security advisories and patches are available through GitHub Security Advisory GHSA-36xw-fx78-c5r4 and GitHub Release v1.4.3. Distribution-specific packages are available via Debian Security Advisory DSA-4865 and Fedora Package Announcement.

Workarounds

• Avoid running containers with host network namespace access (--net=host or hostNetwork: true)
• Ensure containers do not run with an effective UID of 0 where possible
• Implement AppArmor policies to deny access to abstract sockets by adding deny unix addr=@**, to container profiles
• Use isolated namespaces and reduced privilege sets for all containers

# AppArmor configuration to deny abstract socket access
# Add this line to your AppArmor profile for containers
deny unix addr=@**,

# Example: Run containers without host network and as non-root
docker run --net=bridge --user 1000:1000 your-image

# Kubernetes: Ensure hostNetwork is false and runAsNonRoot is true
# In your pod specification:
# spec:
#   hostNetwork: false
#   securityContext:
#     runAsNonRoot: true
#     runAsUser: 1000