ghsa-p4rx-7wvg-fwrc
Vulnerability from github
Published
2024-01-10 15:27
Modified
2024-01-10 15:27
Severity ?
6.5 (Medium) - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Summary
CRI-O's pods can break out of resource confinement on cgroupv2
Details

Impact

What kind of vulnerability is it? Who is impacted? All versions of CRI-O running on cgroupv2 nodes. Unchecked access to an experimental annotation allows a container to be unconfined. Back in 2021, support was added to support an experimental annotation that allows a user to request special resources in cgroupv2. It was supposed to be gated by an experimental annotation: io.kubernetes.cri-o.UnifiedCgroup, which was supposed to be filtered from the list of allowed annotations . However, there is a bug in this code which allows any user to specify this annotation, regardless of whether it's enabled on the node. The consequences of this are a pod can specify any amount of memory/cpu and get it, circumventing the kubernetes scheduler, and potentially be able to DOS a node.

Patches

Has the problem been patched? What versions should users upgrade to? 1.29.1, 1.28.3, 1.27.3

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading? use cgroupv1

References

Are there any links users can visit to find out more?

Show details on source website

To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cri-o/cri-o"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.29.0"
            },
            {
              "fixed": "1.29.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.29.0"
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cri-o/cri-o"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.28.0"
            },
            {
              "fixed": "1.28.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cri-o/cri-o"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.27.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-6476"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-01-10T15:27:45Z",
    "nvd_published_at": "2024-01-09T22:15:43Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\nAll versions of CRI-O running on cgroupv2 nodes. \nUnchecked access to an experimental annotation allows a container to be unconfined. Back in 2021, [support was added](https://github.com/cri-o/cri-o/pull/4479) to support an experimental annotation that allows a user to request special resources in cgroupv2. It was supposed to be gated by an experimental annotation: `io.kubernetes.cri-o.UnifiedCgroup`, which was supposed to be filtered from the [list of allowed annotations](https://github.com/cri-o/cri-o/blob/main/pkg/config/workloads.go#L103-L107) . However, there is a bug in this code which allows any user to specify this annotation, regardless of whether it\u0027s enabled on the node. The consequences of this are a pod can specify any amount of memory/cpu and get it, circumventing the kubernetes scheduler, and potentially be able to DOS a node. \n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n1.29.1, 1.28.3, 1.27.3\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\nuse cgroupv1\n\n### References\n_Are there any links users can visit to find out more?_\n",
  "id": "GHSA-p4rx-7wvg-fwrc",
  "modified": "2024-01-10T15:27:45Z",
  "published": "2024-01-10T15:27:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cri-o/cri-o/security/advisories/GHSA-p4rx-7wvg-fwrc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6476"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cri-o/cri-o/pull/4479"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cri-o/cri-o/commit/75effcb1a25851a736e82dba1f7d8cee93ee159e"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:0195"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:0207"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2023-6476"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2253994"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cri-o/cri-o"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cri-o/cri-o/blob/main/pkg/config/workloads.go#L103-L107"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "CRI-O\u0027s pods can break out of resource confinement on cgroupv2"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.