Описание
A symlink following vulnerability was found in KubeVirt's virt-handler migration proxy. During live migration, virt-handler dials Unix sockets inside the target virt-launcher pod via /proc//root/ paths using net.Dial() without symlink protection. These socket paths reside in qemu-owned directories writable by the virt-launcher user. An attacker with namespace edit and pods/exec permissions can replace a migration proxy socket with a symlink to the host CRI-O socket. Because virt-handler runs as root in the host mount namespace, absolute symlink targets resolve against the host filesystem, and the bidirectional io.Copy proxy relays attacker-controlled bytes to the container runtime, enabling full node compromise.
Отчет
Red Hat has rated this vulnerability as Important impact. The vulnerable code is in the virt-handler component, a privileged DaemonSet running as root in the host mount namespace on every compute node. Its migration proxy dials Unix sockets inside target virt-launcher pods via /proc//root/ using net.Dial(), which follows symbolic links. Because virt-handler operates in the host mount namespace, absolute symlink targets resolve against the host root filesystem, enabling container-to-host escape. Exploitation requires an authenticated user with namespace-level edit permissions (kubevirt.io:edit) and pods/exec access — standard permissions for VM operators. The impact of successful exploitation is complete node compromise via CRI-O socket access, bypassing all Kubernetes admission controls.
Меры по смягчению последствий
Restrict pods/exec permissions in namespaces that run virtual machines. The pods/exec RBAC permission is required for the attack — removing it from VM operator roles prevents exploitation. Additionally, enable Kubernetes audit logging and monitor for kubectl exec commands targeting virt-launcher pods, especially during live migration events.
Дополнительная информация
Статус:
8.8 High
CVSS3
Связанные уязвимости
A symlink following vulnerability was found in KubeVirt's virt-handler migration proxy. During live migration, virt-handler dials Unix sockets inside the target virt-launcher pod via /proc/<pid>/root/ paths using net.Dial() without symlink protection. These socket paths reside in qemu-owned directories writable by the virt-launcher user. An attacker with namespace edit and pods/exec permissions can replace a migration proxy socket with a symlink to the host CRI-O socket. Because virt-handler runs as root in the host mount namespace, absolute symlink targets resolve against the host filesystem, and the bidirectional io.Copy proxy relays attacker-controlled bytes to the container runtime, enabling full node compromise.
A symlink following vulnerability was found in KubeVirt's virt-handler migration proxy. During live migration, virt-handler dials Unix sockets inside the target virt-launcher pod via /proc/<pid>/root/ paths using net.Dial() without symlink protection. These socket paths reside in qemu-owned directories writable by the virt-launcher user. An attacker with namespace edit and pods/exec permissions can replace a migration proxy socket with a symlink to the host CRI-O socket. Because virt-handler runs as root in the host mount namespace, absolute symlink targets resolve against the host filesystem, and the bidirectional io.Copy proxy relays attacker-controlled bytes to the container runtime, enabling full node compromise.
8.8 High
CVSS3