REDHAT-BUG-2548382: High severity gVisor gvproxy vulnerability
A path-traversal flaw was found in gvproxy (gvisor-tap-vsock) in the port-forwarder's /services/forwarder/expose REST endpoint. When invoked with protocol=unix, the caller-supplied local field was passed without any validation to os.Remove() followed by net.Listen("unix", ...) on the host filesystem. Because this endpoint is exposed unauthenticated on the VM gateway (192.168.127.1:80), a process inside the guest VM — including an unprivileged container — could send a single HTTP POST to delete an arbitrary file owned by the gvproxy user on the host and replace it with a unix-socket inode. This crosses the container/VM-to-host isolation boundary, allowing destruction of sensitive host files (SSH keys, kubeconfig, shell/registry configuration) and denial of service. The issue was fixed by removing the os.Remove() call so pre-existing files can no longer be deleted or overwritten.
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue?
Any process inside the guest VM that can reach the VM gateway at 192.168.127.1:80 can invoke the affected endpoint without authentication. The description specifically includes unprivileged containers running inside the guest VM.
What access does an attacker need?
The attacker needs the ability to send a single HTTP POST to the port-forwarder expose endpoint with protocol=unix. No authentication to that endpoint is required.
What is the impact on the host?
An attacker can delete arbitrary files owned by the gvproxy user and replace them with a Unix socket inode. This can destroy sensitive host files, including SSH keys, kubeconfig, and shell or registry configuration, and can cause denial of service.
What changes in the fix?
The fix removes the os.Remove() call used before creating the Unix socket. Pre-existing host files can therefore no longer be deleted or overwritten through this endpoint.