GitHub Security Advisory: GHSA-7xgm-5prm-v5gc
Package: kubevirt.io/kubevirt (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-269: Improper Privilege Management, CWE-276: Incorrect Default Permissions
Vulnerable versions: < 1.7.0
Patched in: 1.7.0

Summary: KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Details:
### Summary

The permissions granted to the `virt-handler` service account, such as the ability to update VMI and patch nodes, could be abused to force a VMI migration to an attacker-controlled node.

### Details

Following the [GitHub security advisory published on March 23 2023](https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2), a `ValidatingAdmissionPolicy` was introduced to impose restrictions on which sections of node resources the `virt-handler` service account can modify. For instance, the `spec` section of nodes has been made immutable, and modifications to the `labels` section are now limited to `kubevirt.io`-prefixed labels only. This vulnerability could otherwise allow an attacker to mark all nodes as unschedulable, potentially forcing the migration or creation of privileged pods onto a compromised node.


However, if a `virt-handler` service account is compromised, either through the pod itself or the underlying node, an attacker may still modify node labels, both on the compromised node and on other nodes within the cluster. Notably, `virt-handler` sets a specific `kubevirt.io` boolean label, `kubevirt.io/schedulable`, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to `false`, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

[Another finding](https://github.com/kubevirt/kubevirt/security/advisories/GHSA-ggp9-c99x-54gp) describes how a compromised `virt-handler` instance can perform operations on other nodes that are intended to be executed solely by `virt-api`. This significantly increases both the impact and the likelihood of the vulnerability being exploited


Additionally, by default, the `virt-handler` service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's `NodeRestriction` feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.



### PoC

By injecting incorrect data into a running VMI, for example, by altering the `kubevirt.io/nodeName` label to reference a different node, the VMI is marked as terminated and its state transitions to `Succeeded`. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

```yaml
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          int