GHSA-rr59-xxvx-96qr: Kata Containers have VM Escape via virtiofsd Argument Injection through Default-Enabled Pod Annotations
SummaryKata Containers ships with a default configuration that allows pod creators to inject arbitrary command-line arguments into the virtiofsd process through the `io.katacontainers.config.hypervisor.virtio_fs_extra_args` pod annotation. By injecting `-o source=/` along with `--no-announce-submounts` and `--sandbox=none`, an attacker can override the virtiofsd shared directory to serve the entire host root filesystem into the guest VM. Combined with the `kernel_params` annotation (also enabled by default) to activate the agent debug console, the attacker can mount the host filesystem from inside the VM and read or write any file on the host, including /etc/shadow.DetailsThe default Kata configuration at configuration.toml line 1 contains:Both `virtio_fs_extra_args` and `kernel_params` are enabled out of the box. The annotation name is checked against this allowlist, but the annotation value (the actual arguments) is never validated or filtered.In utils.go at line 981, the runtime parses the annotation value as a JSON string array and appends it directly to the virtiofsd arguments:In virtiofsd.go at line 183-198, the runtime builds the virtiofsd command line with `--shared-dir=<kata_managed_path>` first, then appends the extra args:The virtiofsd binary (Rust, from gitlab.com/virtio-fs/virtiofsd) supports a compatibility option `-o source=PATH` that overrides the `--shared-dir` value. This is processed after clap argument parsing, in the `parse_compat()` function at main.rs:462:Because `-o source=/` is appended after `--shared-dir=<kata_path>`, it overrides the shared directory to `/`. The virtiofsd process then serves the entire host root filesystem through the virtio-fs device.Additionally, virtiofsd's `--announce-submounts` flag (set by default) causes the guest kernel to create FUSE automounts for bind mounts within the shared directory. When the shared directory is `/`, this produces automounts that shadow the root directory listing. Injecting `--no-announce-submounts` disables this behavior and exposes the true host root directory contents through the kataShared virtiofs mount.The `kernel_params` annotation is used to inject `agent.debug_console agent.debug_console_vport=1026` into the VM kernel command line. This enables a root shell inside the VM through the kata-runtime exec command. From this shell, the attacker mounts the kataShared virtiofs filesystem and accesses host files directly.Rootfs bridge (PoC artifact, not a real constraint)When virtiofsd uses `-o source=/` to serve the host root, the Kata agent looks for the container rootfs at `/<container-id>/rootfs` relative to the virtiofs root. The PoC pre-creates this directory on the host to keep the demonstration self-contained with ctr.In a real Kubernetes attack, there are several ways to satisfy this without hostPath volumes. An initContainer that runs before the target container can create the directory. Alternatively, the attacker can set up a second pod that writes to a shared persistent volume mounted on the host. The rootfs bridge is a PoC convenience, not a limitation of the vulnerability itself.ImpactAn attacker who can create pods on a Kubernetes cluster using Kata Containers with default configuration can:Read any file on the host, including /etc/shadow, SSH private keys, and service credentialsWrite to any file on the host, enabling persistent backdoors, cron jobs, or binary replacementAccess other containers' data through the host filesystemCompromise the Kubernetes control plane if it runs on the same hostSteps to reproduceTested on a bare metal server (AMD Ryzen 5 3600, Ubuntu 24.04, kernel 6.8.0-100-generic) with Kata Containers 3.28.0 installed from the official release tarball.Install Kata Containers 3.28.0 and configure containerd. Verify that the default configuration has virtio_fs_extra_args in enable_annotations.Pull a container image:Run the PoC script below, or follow the manual steps:Manual steps:a. Extract a container rootfs and create the rootfs bridge (replace $SB_ID with your container name):b. Create a marker file on the host to prove access:c. Start the container with the malicious annotations:Wait 20-30 seconds for the VM to start. Verify with `ctr task ls`.d. Enter the VM through the debug console:e. Inside the VM, mount the host filesystem and read host files:f. Observe that /etc/hostname returns the host's hostname (not "localhost"), /etc/os-release shows the host OS (Ubuntu, not Alpine), /etc/shadow shows the host's password hashes, and /opt/kata/bin/ lists the Kata binaries installed on the host.Clean up:Proof of concept outputBelow is the output from a successful run on Kata Containers 3.28.0. The host runs Ubuntu 24.04. The container image is Alpine Linux.The host's real hostname (kata-poc), OS (Ubuntu 24.04.3 LTS), /etc/shadow content, kernel files in /boot, and Kata binaries in /opt/kata/bin are all visible from inside the VM. The container itself runs Alpine, confirming this is the host filesystem and not the container's own filesystem.
CVSS v4.0: 5.8