l3montree-dev / l3montree-dev/devguard
GHSA-33vj-92qq-66hc found in golang/github.com/containerd/containerd/v2@v2.3.1
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 161
- Forks
- 43
- Avg merge
- 1d 8h
- Merged PRs (30d)
- 37
Description
GHSA-33vj-92qq-66hc found in golang/github.com/containerd/containerd/v2@v2.3.1
[!important]
Risk:2.26 (Low)
CVSS:8.4
Description
Impact
containerd's CRI implementation improperly trusts Container Device Interface (CDI) annotations found within untrusted checkpoint image metadata during container restoration. When restoring a container from a checkpoint, containerd preserves CDI-related annotations from the checkpoint archive rather than relying solely on the pod's create-time specification. This allows a user with pod creation permissions to bypass standard Kubernetes resource allocation and device plugin enforcement, injecting arbitrary CDI edits (such as device nodes and host mounts) into the restored container. Successful exploitation requires that the node has CDI enabled and contains a matching host CDI specification for the requested device; environments where CDI is disabled or lacking sensitive device specifications are not affected.
Patches
This bug has been fixed in the following containerd versions:
- 2.3.2
- 2.2.5
- 2.1.9
Users should update to these versions to resolve the issue. Recreating existing containers restored from untrusted checkpoints may be necessary to remove smuggled configuration.
Workarounds
Users can mitigate this issue by restricting the restoration of containers from untrusted checkpoint images. If Container Device Interface (CDI) capabilities are not utilized on the node, removing or temporarily relocating host CDI specifications from the default directories (/etc/cdi and /var/run/cdi) will eliminate the reachability of this vulnerability.
Credits
The containerd project would like to thank Robert Prast (@robertprast) for responsibly disclosing this issue in accordance with the containerd security policy.
For more information
If you have any questions or comments about this advisory:
- Open an issue in containerd
- Email us at security@containerd.io
To report a security issue in containerd:
- Report a new vulnerability
- Email us at security@containerd.io
Affected component
The vulnerability is in pkg:golang/github.com/containerd/containerd/v2@v2.3.1, found in artifacts pkg:oci/devguard-k8s-image-inventory?repository_url=ghcr.io/l3montree-dev/devguard-k8s-image-inventory&arch=amd64&tag=main-amd64, pkg:oci/devguard-k8s-image-inventory?repository_url=ghcr.io/l3montree-dev/devguard-k8s-image-inventory&arch=arm64&tag=main-arm64.
Recommended fix
Upgrade to version v2.3.2 or later.
# Update all golang packages
go get -u ./...
# Update only this package
go get v2@v2.3.2
Additional guidance for mitigating vulnerabilities
Visit our guides on devguard.org
See more details...
Path to component
%%{init: { 'theme':'base', 'themeVariables': {
'primaryColor': '#F3F3F3',
'primaryTextColor': '#0D1117',
'primaryBorderColor': '#999999',
'lineColor': '#999999',
'secondaryColor': '#ffffff',
'tertiaryColor': '#ffffff'
} }}%%
flowchart TD
Your_application(["Your application"]) --- pkg_golang_github_com_containerd_containerd_v2_v2_3_1(["pkg:golang/github.com/containerd/containerd/v2\@v2.3.1"])
classDef default stroke-width:2px
| Risk Factor | Value | Description |
|---|---|---|
| Vulnerability Depth | 1 |
The vulnerability is in a direct dependency of your project. |
| EPSS | 0.35 % |
The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days. |
| EXPLOIT | Not available |
We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database. There are no script kiddies exploiting this vulnerability. |
| CVSS-BE | 7.3 |
|
| CVSS-B | 8.4 |
- The vulnerability can be exploited over the network without needing physical access. - It is easy for an attacker to exploit this vulnerability. - An attacker needs basic access or low-level privileges. - No user interaction is needed for the attacker to exploit this vulnerability. |
More details can be found in DevGuard
Interact with this vulnerability
You can use the following slash commands to interact with this vulnerability:
👍 Reply with this to acknowledge and accept the identified risk.
/accept I accept the risk of this vulnerability, because ...
⚠️ Mark the risk as false positive: Use one of these commands if you believe the reported vulnerability is not actually a valid issue.
/component-not-present The vulnerable component is not included in the artifact.
/vulnerable-code-not-present The component is present, but the vulnerable code is not included or compiled.
/vulnerable-code-not-in-execute-path The vulnerable code exists, but is never executed at runtime.
/vulnerable-code-cannot-be-controlled-by-adversary Built-in protections prevent exploitation of this vulnerability.
/inline-mitigations-already-exist The vulnerable code cannot be controlled or influenced by an attacker.
🔁 Reopen the risk: Use this command to reopen a previously closed or accepted vulnerability.
/reopen ...
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Locate the Go dependency manifest for github.com/containerd/containerd/v2 and check where version v2.3.1 is selected. Update it to v2.3.2 or later, then run the repository's existing Go dependency, build, or test checks to confirm the vulnerable version is no longer included.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- security
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 62/100