Vulnerabilities in Docker, other container engines enable host OS access
Security researchers have found four vulnerabilities in Docker components that could allow attackers to access host operating systems from within containers. One of those vulnerabilities is in runc, a command-line tool for spawning and running containers on Linux that underpins multiple container engines, not just Docker.
The vulnerabilities were found by Rory McNamara, a researcher with cloud security firm Snyk who collectively named them “Leaky Vessels” because they allow breaking the critical isolation layer between containers and the host operating system. “These container escapes could allow an attacker to gain unauthorized access to the underlying host operating system from within the container and potentially permit access to sensitive data (credentials, customer info, etc.), and launch further attacks, especially when the access gained includes superuser privileges,” Snyk said in a blog post.
Vulnerability provides multiple attack paths from runc
Runc can be viewed as the plumbing that ties most container management engines such as Docker, containerd, Podman, and CRI-O to the Linux kernel’s sandboxing features: control groups, namespaces, seccomp, apparmor, and so on. It supports multiple commands for starting, stopping, suspending, pausing, and listing containers, as well as executing processes inside containers.
The runc vulnerability found by McNamara, tracked as CVE-2024-21626, stems from a file descriptor being inadvertently leaked internally within runc, including a handle to the host’s /sys/fs/cgroup. This can be exploited in multiple ways, one found by McNamara and three others found by runc maintainers.
“If the container was configured to have process.cwd set to /proc/self/fd/7/ (the actual fd can change depending on file opening order in runc), the resulting pid1 process will have a working directory in the host mount namespace and thus the spawned process can access the entire host filesystem,” the runc maintainers warn in an advisory. “This alone is not an exploit against runc. However, a malicious image could make any innocuous-looking non-/ path a symlink to /proc/self/fd/7/ and thus trick a user into starting a container whose binary has access to the host filesystem.”
This exploit targets the runc run command, which is used to create and start a new container from an image. Many containers are started from images downloaded from public repositories such as Docker Hub and malicious images have been uploaded to the registry over time.
