REDHAT-BUG-2517502: High severity Kata Containers vulnerability
In Kata Containers configurations that use genpolicy for Confidential Containers guest protection, insufficient validation of CreateContainer mount and storage rules allows a malicious host operator to craft CreateContainer requests that cause arbitrary container-rootfs paths to be mounted over host-provided locations (such as /etc/hostname, /etc/hosts, /etc/resolv.conf, Kubernetes/Azure service-account token paths, and other volume mounts), or to provision arbitrary content under /dev/shm and /dev/termination-log. Applications that treat those paths as non-sensitive or guest-only may expose confidential information or accept attacker-controlled input. Standard Kata sandboxing is not affected.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In Kata Containers configurations that use genpolicy for Confidential Containers guest protection, ensure CreateContainer mount and storage rules validate inputs so a malicious host operator cannot specify arbitrary container-rootfs paths to be mounted over host-provided locations (e.g., /etc/hostname, /etc/hosts, /etc/resolv.conf, service-account token paths) or provision arbitrary content under /dev/shm and /dev/termination-log.
Event History
Frequently Asked Questions
Which deployments are affected?
The issue affects Kata Containers configurations that use genpolicy for Confidential Containers guest protection. Standard Kata sandboxing is not affected.
What level of access does an attacker need?
An attacker must be a malicious host operator able to craft CreateContainer requests. The issue is triggered through insufficient validation of CreateContainer mount and storage rules.
What could an attacker control or expose?
The attacker can cause arbitrary container-rootfs paths to be mounted over host-provided locations, including hostname, hosts, resolver, service-account token, and other volume-mount paths. They may also provision arbitrary content under /dev/shm and /dev/termination-log, potentially causing applications to disclose confidential information or consume attacker-controlled input.