{
  "schema_version": "1.4.0",
  "id": "GHSA-cp96-jpmq-xrr2",
  "modified": "2023-03-27T22:24:34Z",
  "published": "2023-03-16T16:04:42Z",
  "aliases": [
    "CVE-2023-26484"
  ],
  "summary": "On a compromised node, the virt-handler service account can be used to modify all node specs",
  "details": "### Impact\n\nIf a malicious user has taken over a Kubernetes node where virt-handler (the KubeVirt node-daemon) is running, the virt-handler service account can be used to modify all node specs.\n\nThis can be misused to lure-in system-level-privileged components (which can for instance read all secrets on the cluster, or can exec into pods on other nodes). This way a compromised node can be used to elevate privileges beyond the node until potentially having full privileged access to the whole cluster.\n\nThe simplest way to exploit this, once a user could compromise a specific node, is to set with the virt-handler service account all other nodes to unschedulable and simply wait until system-critical components with high privileges appear on its node.\n\nSince this requires a node to be compromised first, the severity of this finding is considered Medium.\n\n### Patches\n\nNot yet available.\n\n### Workarounds\nGatekeeper users can add a webhook which will block the `virt-handler` service account to modify the spec of a node.\n\nAn example policy, preventing virt-handler from changing the node spec may look like this:\n\n```yaml\napiVersion: templates.gatekeeper.sh/v1\nkind: ConstraintTemplate\nmetadata:\n  name: virthandlerrestrictions\nspec:\n[...]\n  targets:\n    - libs:\n        - |         \n[...]          \n          is_virt_handler(username) {\n              username == \"system:serviceaccount:kubevirt:virt-handler\"\n          }\n          mutates_node_in_unintended_way {\n            # TODO\n            # only allow kubevirt.io/ prefixed metadata node changes\n          }\n      rego: |\n[...]\n        \n        violation[{\"msg\": msg}] {\n          is_virt_handler(username)\n          mutates_node_in_unintended_way(input.review.object, input.review.oldObject)\n          msg := sprintf(\"virt-handler tries to modify node <%v> in an unintended way.\", [input.review.object.name])\n        }\n```\n\nand applying this template to node modifications.\n\n\n### Credits\n\nSpecial thanks to the discoverers of this issue:\n\nNanzi Yang (nzyang@stu.xidian.edu.cn)\nXin Guo (guox@stu.xidian.edu.cn)\nJietao Xiao (jietaoXiao@stu.xidian.edu.cn)\nWenbo Shen (shenwenbo@zju.edu.cn)\nJinku Li (jkli@xidian.edu.cn)\n\n### References\n\nhttps://github.com/kubevirt/kubevirt/issues/9109",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N"
    }
  ],
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "kubevirt.io/kubevirt"
      },
      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.59.0"
            }
          ]
        }
      ]
    }
  ],
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26484"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubevirt/kubevirt/issues/9109"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kubevirt/kubevirt"
    }
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "severity": "HIGH",
    "github_reviewed": true,
    "github_reviewed_at": "2023-03-16T16:04:42Z",
    "nvd_published_at": "2023-03-15T21:15:00Z"
  }
}