Listen to this Post
The vulnerability in KubeVirt’s hostDisk feature with the `DiskOrCreate` type allows arbitrary file read/write on the host. A logic bug exists in the `virt-handler` component. When a user defines a volume with `type: DiskOrCreate` and a path to a host file, the code checks if the file exists. If the file does not exist, it creates a sparse file. Crucially, the code then changes the file’s ownership to UID 107 (the qemu user) regardless of whether the file was just created or already existed. This means an attacker can specify the path to a critical host file, like /etc/passwd. If the file exists, its ownership is forcibly changed to UID 107, allowing the QEMU process in the VM to read and write to it, bypassing the intended ownership-based security restrictions and compromising host file integrity and confidentiality.
Platform: KubeVirt
Version: v1.2.0
Vulnerability: Logic Bug
Severity: Critical
date: 2024-04-30
Prediction: 2024-05-30
What Undercode Say:
kubectl apply -f kubevirt-cr.yaml kubectl get vm kubectl exec -it virt-launcher-pod -- ls -al /var/run/kubevirt-private/vmi-disks/host-disk/target-file virtctl console vulnerable-vm cat /dev/vdc echo "malicious" >> /dev/vdc
// pkg/host-disk/host-disk.go
func (hdc DiskImgCreator) mountHostDiskAndSetOwnership(...) error {
// ...
if !fileExists {
hdc.handleRequestedSizeAndCreateSparseRaw(vmi, diskDir, diskPath, hostDisk) // Creates file
}
ephemeraldiskutils.DefaultOwnershipManager.UnsafeSetFileOwnership(diskPath) // Always changes ownership to 107
}
How Exploit:
Create VM manifest.
Use `DiskOrCreate` type.
Specify privileged host path.
Deploy VM.
Ownership changes automatically.
Read/write from VM.
Protection from this CVE:
Disable HostDisk feature.
Update KubeVirt version.
Use PodSecurityPolicy.
Restrict VM permissions.
Impact:
Host File Read
Host File Write
System Compromise
Data Corruption
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
