Headline
CVE-2023-26484: A potential risk of kubevirt makes a worker node get the cluster's admin secret. · Issue #9109 · kubevirt/kubevirt
KubeVirt is a virtual machine management add-on for Kubernetes. In versions 0.59.0 and prior, if 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. This 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. The 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. No patches are available as of time of publication. As a workaround, gatekeeper users can add a webhook which will block the virt-handler service account to modify the spec of a node.
Description:
- There are three components of kubevirt with default installation: kubevirt-handler, kubevirt-controller, kubevirt-api, and kubevirt-operator, the kubevirt-handler is a daemon set running on each node, the controller&api&operator are deployments, each of them is two-pod deployments running on worker nodes randomly.
- There are different cluster roles of these components:
- The cluster role of the kubevirt-handler can patch nodes, which can be leveraged to make nodes unschedulable.
- The cluster role of the kubevirt-controller can create pods/eviction, which can be leveraged to make pods evicted. While the cluster role of kubevirt-api can delete pods, which can be leveraged to make pods recreated and rescheduled to worker nodes.
- The cluster role of the kubevirt-operator can list all secrets, which can be leveraged to get the admin secret of the entire cluster and make cluster-level privilege escalation.
- If a malicious user controls a worker node, which has kubevirt-handler, and one of kubevirt-api/controller:
- He/she can leverage the kubevirt-handler to path all other nodes with unschedulable: true". And when the kubevirt-operator is rescheduled, the kubevirt-operator will be rescheduled to the malicious worker node.
- He/She can use the token of kubevirt-api/controller to evict/delete kubevirt-operator pods, which will be recreated and run on the malicious worker node.
- After the kubevirt-operator runs on the malicious worker node, he/she can leverage the operator’s token to list all secrets in the whole cluster, get the cluster admin’s token and make a cluster-level privilege escalation.
- Mitigation Discussion:
- The cluster role of the kubevirt-operator can use the Resource Names to restrain the secrets which can be listed by the operator itself, however, it may need a careful review of the kubevirt-operator to identify all secrets needed by the operator exactly.
- The kubevirt-handler can remove the patch verbs of nodes, and the controller/api can remove the evict and delete of pods. However, similar to the first mitigation, it still needs a careful revisit of the components’ source code.
- The kubevirt can let the kubevirt-operator/controller/api runs on worker nodes (which we called “controller worker node”) without running users’ workloads, and leverage the isolation of nodes to mitigate the risk. However, if a malicious user leverages some method(i.e., scale-up of kubevirt-handler) and moves to the “controller worker node” horizontally, it still can break the worker nodes’ isolation and make privilege escalation.
- Installation and environment:
- We follow the Kubevirt’s official guide to install the Kubevirt on a four-node Kubernetes cluster(1.24.2).
I’m looking forward to hearing back from you!
- We follow the Kubevirt’s official guide to install the Kubevirt on a four-node Kubernetes cluster(1.24.2).
Related news
### Impact If 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. This 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. The 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. Since this requires a node to be compromised first, the severity of this finding is considered Medium. ### Patches Not yet available. ### Workarounds Gatekeeper users can add a webhook which will block the `virt-handler` service account to...