GHSA-W2J5-3RCX-VX7X

Vulnerability from github – Published: 2022-03-15 20:02 – Updated: 2022-03-15 20:02
VLAI
Summary
Sysctls applied to containers with host IPC or host network namespaces can affect the host
Details

Impact

Before setting the sysctls for a pod, the pods namespaces must be unshared (created). However, in cases where the pod is using a host network or IPC namespace, a bug in CRI-O caused the namespace creating tool pinns to configure the sysctls of the host. This allows a malicious user to set sysctls on the host, assuming they have access to hostNetwork and hostIPC.

Any CRI-O cluster after CRI-O 1.18 that drops the infra container 1.22 and 1.23 clusters drop infra container by default, and are thus vulnerable by default.

Patches

CRI-O versions 1.24.0, 1.23.1, 1.22.2, 1.21.5, 1.20.6, 1.19.5 all have the patches.

Workarounds

Users can set manage_ns_lifecycle to false, which causes the sysctls to be configured by the OCI runtime, which typically filter these cases. This option is available in 1.20 and 1.19. Newer versions don't have this option. An admission webhook could also be created to deny pods that use host IPC or network namespaces and also attempt to configure sysctls related to that namespace.

For more information

If you have any questions or comments about this advisory: * Open an issue in the CRI-O repo * To make a report, email your vulnerability to the private cncf-crio-security@lists.cncf.io list with the security details and the details expected for all CRI-O bug reports.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cri-o/cri-o"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.23.0"
            },
            {
              "fixed": "1.23.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cri-o/cri-o"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.22.0"
            },
            {
              "fixed": "1.22.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cri-o/cri-o"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.21.0"
            },
            {
              "fixed": "1.21.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cri-o/cri-o"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.20.0"
            },
            {
              "fixed": "1.20.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cri-o/cri-o"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.18.0"
            },
            {
              "fixed": "1.19.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": true,
    "github_reviewed_at": "2022-03-15T20:02:54Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\nBefore setting the sysctls for a pod, the pods namespaces must be unshared (created). However, in cases where the pod is using a host network or IPC namespace, a bug in CRI-O caused the namespace creating tool [pinns](https://github.com/cri-o/cri-o/tree/main/pinns/) to configure the sysctls of the host. This allows a malicious user to set sysctls on the host, assuming they have access to hostNetwork and hostIPC.\n\nAny CRI-O cluster after CRI-O 1.18 that drops the infra container\n1.22 and 1.23 clusters drop infra container by default, and are thus vulnerable by default.\n\n### Patches\nCRI-O versions 1.24.0, 1.23.1, 1.22.2, 1.21.5, 1.20.6, 1.19.5 all have the patches.\n\n### Workarounds\nUsers can set `manage_ns_lifecycle` to false, which causes the sysctls to be configured by the OCI runtime, which typically filter these cases. This option is available in 1.20 and 1.19. Newer versions don\u0027t have this option.\nAn admission webhook could also be created to deny pods that use host IPC or network namespaces and also attempt to configure sysctls related to that namespace.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [the CRI-O repo](http://github.com/cri-o/cri-o/issues)\n* To make a report, email your vulnerability to the private\n[cncf-crio-security@lists.cncf.io](mailto:cncf-crio-security@lists.cncf.io) list\nwith the security details and the details expected for [all CRI-O bug\nreports](https://github.com/cri-o/cri-o/blob/main/.github/ISSUE_TEMPLATE/bug-report.yml).",
  "id": "GHSA-w2j5-3rcx-vx7x",
  "modified": "2022-03-15T20:02:54Z",
  "published": "2022-03-15T20:02:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cri-o/cri-o/security/advisories/GHSA-w2j5-3rcx-vx7x"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cri-o/cri-o"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Sysctls applied to containers with host IPC or host network namespaces can affect the host"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…