Skip to content
Log inStart free trial

GHSA-hmfx-3pcx-653p CVE-2023-25173 GO-2023-1574

Supplementary groups are not set up properly in github.com/containerd/containerd

High Go
Severity
5.3 / 10
High · CVSS 3.0
Exploit chance (EPSS)
0.54%
Chance of exploitation in the next 30 days. Higher than 45.56% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-269 Improper Privilege Management
CWE-863 Incorrect Authorization
Fix
1.5.18
Upgrade github.com/containerd/containerd to this version or later

Description

Impact

A bug was found in containerd where supplementary groups are not set up properly inside a container. If an attacker has direct access to a container and manipulates their supplementary group access, they may be able to use supplementary group access to bypass primary group restrictions in some cases, potentially gaining access to sensitive information or gaining the ability to execute code in that container.

Downstream applications that use the containerd client library may be affected as well.

Patches

This bug has been fixed in containerd v1.6.18 and v.1.5.18. Users should update to these versions and recreate containers to resolve this issue. Users who rely on a downstream application that uses containerd's client library should check that application for a separate advisory and instructions.

Workarounds

Ensure that the "USER $USERNAME" Dockerfile instruction is not used. Instead, set the container entrypoint to a value similar to ENTRYPOINT ["su", "-", "user"] to allow su to properly set up supplementary groups.

References

Note that CVE IDs apply to a particular implementation, even if an issue is common.

For more information

If you have any questions or comments about this advisory:

To report a security issue in containerd:

Affected versions

Go

PackageVulnerableFixed in
github.com/containerd/containerd
< 1.5.18
1.5.18
github.com/containerd/containerd
>= 1.6.0, < 1.6.18
1.6.18
github.com/containerd/containerd
< 1.5.18
>= 1.6.0, < 1.6.18
1.5.18
1.6.18

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

github.com/containerd/containerd Go → 1.5.18

go
go get github.com/containerd/containerd@v1.5.18 && go mod tidy

Severity breakdown

CVSS 3.0 5.3

CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L

Attack vector
Local
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
Low
Availability
Low

Weakness

CWE-269: Improper Privilege Management

The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.

How to prevent it
  • Architecture and Design, Operation: Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
  • Architecture and Design: Follow the principle of least privilege when assigning access rights to entities in a software system.
  • Architecture and Design: Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.

CWE-863: Incorrect Authorization

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

How to prevent it
  • Architecture and Design: Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
  • Architecture and Design: Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
  • Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
  • Architecture and Design: For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page. One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
  • System Configuration, Installation: Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

References

Advisories

Write-ups

Packages

Other links

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-phjr-8j92-w5v7
CRI-O incorrect handling of supplementary groups may lead to sensitive information disclosure
High Linked by the source
GHSA-fjm8-m7m6-2fjp
Buildah's incorrect handling of the supplementary groups may lead to data disclosure, modification
High Linked by the source
GHSA-4wjj-jwc9-2x96
Podman's incorrect handling of the supplementary groups may lead to data disclosure, modification
High Linked by the source
GHSA-rc4r-wh2q-q6c4
Docker supplementary group permissions not set up properly, allowing attackers to bypass primary group restrictions
Medium Linked by the source
GHSA-rp3h-jf77-q9p4
containerd: Unpack DoS via repeated opaque whiteouts
Medium Also affects github.com/containerd/containerd
GO-2026-6791
containerd CRI plugin: Checkpoint restore bypasses destination security context
High Also affects github.com/containerd/containerd
GHSA-pg57-6jwg-q645
Containerd has image-pull DoS via crafted OCI index graph amplification
Medium Also affects github.com/containerd/containerd
GHSA-7jxh-36q5-gcqv
containerd: CRI ExecSync Goroutine Leak Leads to Node-Level Denial of Service
Medium Also affects github.com/containerd/containerd
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor