CVE-2023-25173: Containerd Privilege Escalation Vulnerability

CVE-2023-25173 Overview

CVE-2023-25173 is a privilege escalation vulnerability in containerd, an open source container runtime widely used in container orchestration platforms. A bug was discovered in containerd versions prior to 1.6.18 and 1.5.18 where supplementary groups are not properly set up inside a container. This improper authorization flaw (CWE-863) allows attackers with direct access to a container to manipulate their supplementary group access, potentially bypassing primary group restrictions.

Critical Impact

Attackers who gain access to a vulnerable container can leverage improperly configured supplementary groups to access sensitive information or execute code within that container by bypassing primary group restrictions.

Affected Products

• Linux Foundation containerd versions prior to 1.6.18
• Linux Foundation containerd versions prior to 1.5.18
• Downstream applications using the containerd client library

Discovery Timeline

• February 16, 2023 - CVE-2023-25173 published to NVD
• November 21, 2024 - Last updated in NVD database

Technical Details for CVE-2023-25173

Vulnerability Analysis

This vulnerability stems from improper handling of supplementary groups when containers are initialized. In Linux systems, supplementary groups provide an additional layer of access control beyond the primary group. When containerd fails to properly configure these groups, it creates a privilege boundary that can be circumvented by attackers who have gained initial access to the container environment.

The vulnerability is particularly concerning in multi-tenant container environments where supplementary groups are used to enforce access controls to sensitive resources. An attacker who manipulates their supplementary group membership could gain unauthorized access to files, directories, or other resources that should be restricted based on group membership.

Root Cause

The root cause of CVE-2023-25173 lies in the container creation process within containerd's CRI (Container Runtime Interface) server implementation. Specifically, when creating Linux containers, the code path responsible for setting up the container's security context failed to properly propagate supplementary groups from the security context configuration. The specOpts array was only appending additional GIDs based on the user string but was not including the supplementary groups specified in the security context.

Attack Vector

The attack requires local access to a vulnerable container environment. An attacker who has gained initial access to a container (through application vulnerabilities, misconfigurations, or compromised credentials) can exploit this flaw by manipulating their supplementary group access. This could allow them to:

1. Access files and directories restricted by group permissions
2. Execute binaries that require specific group membership
3. Bypass security controls that rely on proper group-based access restrictions

The attack is particularly effective when containers use the USER $USERNAME Dockerfile instruction, as this triggers the vulnerable code path.

 		// Because it is still useful to get additional gids for uid 0.
 		userstr = strconv.FormatInt(securityContext.GetRunAsUser().GetValue(), 10)
 	}
-	specOpts = append(specOpts, customopts.WithAdditionalGIDs(userstr))
+	specOpts = append(specOpts, customopts.WithAdditionalGIDs(userstr),
+		customopts.WithSupplementalGroups(securityContext.GetSupplementalGroups()))
 
 	asp := securityContext.GetApparmor()
 	if asp == nil {

Source: Containerd Security Patch

The fix adds a call to customopts.WithSupplementalGroups() that properly sets supplementary groups from the security context when creating container specifications.

Detection Methods for CVE-2023-25173

Indicators of Compromise

• Unexpected group membership changes within running containers
• Unauthorized access to group-protected resources in container filesystems
• Anomalous file access patterns from containerized processes
• Containers running with unexpected supplementary group configurations

Detection Strategies

• Monitor container runtime logs for unusual group-related operations
• Implement audit logging for file access within containers to detect privilege boundary violations
• Use container security tools to compare expected vs actual group configurations
• Deploy runtime security monitoring to detect anomalous process behavior within containers

Monitoring Recommendations

• Enable verbose logging for containerd to capture container creation details
• Implement file integrity monitoring within containers for sensitive directories
• Monitor for processes attempting to access resources outside their expected group permissions
• Use SentinelOne's container security capabilities to detect runtime privilege escalation attempts

How to Mitigate CVE-2023-25173

Immediate Actions Required

• Update containerd to version 1.6.18 or 1.5.18 or later immediately
• Recreate all existing containers after updating to ensure proper supplementary group configuration
• Review downstream applications using containerd's client library for separate advisories
• Audit container Dockerfiles for usage of the vulnerable USER $USERNAME instruction

Patch Information

The vulnerability has been fixed in containerd versions 1.6.18 and 1.5.18. Users should update to these versions and recreate containers to resolve the issue. The fix is available via the official containerd commit. Release downloads are available from the v1.6.18 release page and v1.5.18 release page.

For additional context, consult the Containerd Security Advisory and related Moby Security Advisory.

Workarounds

• Avoid using USER $USERNAME Dockerfile instruction in container definitions
• Set the container entrypoint to use su for proper supplementary group setup: ENTRYPOINT ["su", "-", "user"]
• Implement additional access controls at the application level that do not rely solely on group-based permissions
• Consider using network policies and other isolation mechanisms to limit the impact of container compromise

# Configuration example - Workaround Dockerfile entrypoint
# Instead of using: USER username
# Use the following entrypoint pattern:
ENTRYPOINT ["su", "-", "user"]

# Verify containerd version after patching
containerd --version
# Expected output should show version 1.6.18+ or 1.5.18+

# Recreate containers after updating containerd
# Example with crictl:
crictl stop <container_id>
crictl rm <container_id>
# Then recreate the container with your orchestration tool