ghsa-h27c-6xm3-mcqp
Vulnerability from github
Published
2024-08-20 22:13
Modified
2024-11-22 23:11
Severity ?
8.8 (High) - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
6.3 (Medium) - CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:U
Summary
Kanister vulnerable to cluster-level privilege escalation
Details

Summary

This advisory affects the Kanister helm charts and not the go package

Details

The kanister has a deployment called default-kanister-operator, which is bound with a ClusterRole called edit via ClusterRoleBinding(https://github.com/kanisterio/kanister/blob/master/helm/kanister-operator/templates/rbac.yaml#L49). The "edit" ClusterRole is one of Kubernetes default-created ClusterRole, and it have create/patch/udpate verbs of daemonset resources, create verb of serviceaccount/token resources, and impersonate verb of serviceaccounts resources. If a malicious user can access the worker node which has this component, he/she can:

For the create/patch/update verbs of daemonset resources, the malicious user can abuse it to create or modify a set of Pods to mount a high-privilege service account (e.g., the cluster-admin service account). After that, he/she can abuse the high-privilege SA token of created Pod to take over the whole cluster.

For the create verb of serviceaccount/token resources, a malicious user can abuse this permission to generate new Service Account tokens and use them to operate with high-privilege roles, such as cluster administrators. These tokens can be used to access and manipulate any resources within the cluster.

For the impersonate verb of serviceaccounts resources, a malicious user can impersonate high-privilege Service Accounts, thereby gaining access to roles such as cluster administrators. This enables the attacker to perform all actions that the high-privilege account can, including creating, modifying, and deleting critical resources within the cluster.

PoC

We have discussed in the "Details" section

Impact

Privilege escalation

Mitigation

Currently kanister helm chart provides rbac.create flag (true by default), which controls whether the rbac rules for kanister service account will be created https://github.com/kanisterio/kanister/blob/master/helm/kanister-operator/values.yaml#L17 If this value set to false, the user needs to create rbac rules themselves and they can limit the role bindings for kanister service account, for example scope it to specific namespace. Service account can also be configured via helm https://github.com/kanisterio/kanister/blob/master/helm/kanister-operator/values.yaml#L19

Show details on source website

To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kanisterio/kanister"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20240926084453-1f40f03d8432"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-43403"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-08-20T22:13:02Z",
    "nvd_published_at": "2024-08-20T22:15:04Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nThis advisory affects the Kanister helm charts and not the go package\n\n### Details\nThe kanister has a deployment called default-kanister-operator, which is bound with a ClusterRole called edit via ClusterRoleBinding(https://github.com/kanisterio/kanister/blob/master/helm/kanister-operator/templates/rbac.yaml#L49). The \"edit\" ClusterRole is one of Kubernetes default-created ClusterRole, and it have create/patch/udpate verbs of daemonset resources, create verb of serviceaccount/token resources, and impersonate verb of serviceaccounts resources. If a malicious user can access the worker node which has this component, he/she can:\n\nFor the create/patch/update verbs of daemonset resources, the malicious user can abuse it to create or modify a set of Pods to mount a high-privilege service account (e.g., the cluster-admin service account). After that, he/she can abuse the high-privilege SA token of created Pod to take over the whole cluster.\n\nFor the create verb of serviceaccount/token resources, a malicious user can abuse this permission to generate new Service Account tokens and use them to operate with high-privilege roles, such as cluster administrators. These tokens can be used to access and manipulate any resources within the cluster.\n\nFor the impersonate verb of serviceaccounts resources, a malicious user can impersonate high-privilege Service Accounts, thereby gaining access to roles such as cluster administrators. This enables the attacker to perform all actions that the high-privilege account can, including creating, modifying, and deleting critical resources within the cluster.\n\n\n### PoC\nWe have discussed in the \"Details\" section\n\n### Impact\nPrivilege escalation\n\n### Mitigation\n\nCurrently kanister helm chart provides rbac.create flag (true by default), which controls whether the rbac rules for kanister service account will be created https://github.com/kanisterio/kanister/blob/master/helm/kanister-operator/values.yaml#L17\nIf this value set to false, the user needs to create rbac rules themselves and they can limit the role bindings for kanister service account, for example scope it to specific namespace.\nService account can also be configured via helm https://github.com/kanisterio/kanister/blob/master/helm/kanister-operator/values.yaml#L19\n",
  "id": "GHSA-h27c-6xm3-mcqp",
  "modified": "2024-11-22T23:11:42Z",
  "published": "2024-08-20T22:13:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kanisterio/kanister/security/advisories/GHSA-h27c-6xm3-mcqp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43403"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kanisterio/kanister"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kanisterio/kanister/blob/master/helm/kanister-operator/templates/rbac.yaml#L49"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kanisterio/kanister/wiki/2023%E2%80%9024-Community-Meeting-Notes"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Kanister vulnerable to cluster-level privilege escalation"
}


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.
  • 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.