GHSA-qw6q-3pgr-5cwq: KubeVirt Arbitrary Container File Read
Summary_Short summary of the problem. Make the impact and severity as clear as possible.Mounting a user-controlled PVC disk within a VM allows an attacker to read any file present in the `virt-launcher` pod. This is due to erroneous handling of symlinks defined within a PVC.Details_Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._A vulnerability was discovered that allows a VM to read arbitrary files from the `virt-launcher` pod's file system. This issue stems from improper symlink handling when mounting PVC disks into a VM. Specifically, if a malicious user has full or partial control over the contents of a PVC, they can create a symbolic link that points to a file within the `virt-launcher` pod's file system. Since `libvirt` can treat regular files as block devices, any file on the pod's file system that is symlinked in this way can be mounted into the VM and subsequently read.Although a security mechanism exists where VMs are executed as an unprivileged user with UID `107` inside the `virt-launcher` container, limiting the scope of accessible resources, this restriction is bypassed due to a second vulnerability (TODO: put link here). The latter causes the ownership of any file intended for mounting to be changed to the unprivileged user with UID `107` prior to mounting. As a result, an attacker can gain access to and read arbitrary files located within the `virt-launcher` pod's file system or on a mounted PVC from within the guest VM.PoC_Complete instructions, including specific configuration details, to reproduce the vulnerability._Consider that an attacker has control over the contents of two PVC (e.g., from within a container) and creates the following symlinks:By default, Minikube's storage controller (`hostpath-provisioner`) will allocate the claim as a directory on the host node (`HostPath`). Once the above Kubernetes resources are created, the user can create the symlinks within the PVC as follows:Of course, these links could potentially be broken as the files, especially `default_arbitrary-container-read.xml`, could not exist on the `dual-pvc-pod` pod's file system. The attacker then deploy the following VM:The two PVCs will be mounted as volumes in "filesystem" mode:From the [documentation](https://kubevirt.io/user-guide/storage/disks_and_volumes/#persistentvolumeclaim) of the different volume modes, one can infer that if the backing `disk.img` is not owned by the unprivileged user with UID `107`, the VM should fail to mount it. In addition, it's expected that this backing file is in [RAW format](https://www.qemu.org/docs/master/tools/qemu-img.html#notes). While this format can contain pretty much anything, we consider that being able to mount a file from the file system of `virt-launcher` is not the expected behaviour. Below is demonstrated that after applying the VM manifest, the guest can read the `/etc/passwd` and `default_migration.xml` files from the `virt-launcher` pod's file system:Impact_What kind of vulnerability is it? Who is impacted?_This vulnerability breaches the container-to-VM isolation boundary, compromising the confidentiality of storage data.
CVSS v3.1: 6.5