Executive Summary

This vulnerability exists in KubeVirt's migration proxy when the setting spec.configuration.migrations.disableTLS is enabled (set to true). In this mode, the migration proxy disables TLS and binds a plain TCP listener on all network interfaces without any authentication, peer allow-list, or handshake token.

Because of this, any attacker with a running pod on the cluster network can connect to this listener and directly issue unfiltered libvirt RPC commands to another tenant's virtual machine. This includes reading VM memory and configuration, modifying VM state, or even destroying the VM.

Even if a dedicated migration network is configured, the listener remains reachable on the pod network because the bind address is always 0.0.0.0, making the port accessible cluster-wide. The documentation misleadingly states that disabling TLS only removes encryption, but it also removes all mutual authentication.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can have severe impacts including unauthorized access to virtual machines running in the cluster. An attacker can:

• Read the memory and configuration of other tenants' virtual machines.
• Modify the state of virtual machines via QEMU Machine Protocol (QMP).
• Destroy virtual machines, causing denial of service.

Since the listener is accessible from any pod on the cluster network, this can lead to cross-tenant attacks and compromise of VM confidentiality, integrity, and availability.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by checking if the KubeVirt migration proxy is running with the spec.configuration.migrations.disableTLS setting set to true, which causes the proxy to bind a plain TCP listener on all interfaces (0.0.0.0/::) without authentication.

To detect the open listener, you can scan the cluster network for open TCP ports on the nodes or pods that correspond to the migration proxy. Since the port is random, a network scan on the pod network for open TCP ports might help identify the exposed listener.

You can also check the KubeVirt custom resource configuration for the disableTLS flag:

• kubectl get kubevirt <kubevirt-resource-name> -o yaml | grep disableTLS

To identify the open TCP listener on all interfaces, you can run commands inside the virt-handler pod or node to list listening ports, for example:

• ss -tlnp | grep <migration-proxy-process>
• netstat -tlnp | grep <migration-proxy-process>

Since the listener binds to 0.0.0.0, you can also attempt to connect to the suspected port from another pod in the cluster to verify if the migration proxy is accessible without authentication.

Useful 0 Not Useful 0

Mitigation Strategies

The immediate mitigation step is to ensure that the spec.configuration.migrations.disableTLS setting is not set to true in the KubeVirt custom resource. Disabling TLS removes both encryption and authentication, exposing the migration proxy to unauthenticated access.

If disableTLS is currently enabled, revert this setting to false or remove it to re-enable TLS, which provides encryption and mutual authentication for the migration proxy.

Additionally, restrict access to the migration proxy by limiting network exposure. Since the listener binds to all interfaces (0.0.0.0), consider network policies or firewall rules to restrict access to trusted pods or networks.

Review and follow the official KubeVirt documentation and advisories for any patches or updates addressing this issue.

Useful 0 Not Useful 0

Compliance Impact

This vulnerability allows unauthorized access to virtual machines' memory and configuration, as well as the ability to modify or destroy VM states. Such unauthorized access and control over sensitive data and systems can lead to violations of data protection and privacy regulations like GDPR and HIPAA, which require strict controls over access to personal and sensitive information.

Specifically, the removal of TLS and authentication when disableTLS is set to true exposes the migration proxy to unauthenticated users within the cluster network, increasing the risk of data breaches and unauthorized data manipulation.

Therefore, organizations using KubeVirt with this configuration may fail to meet compliance requirements related to confidentiality, integrity, and access control mandated by common standards and regulations.

Useful 0 Not Useful 0