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.
Another attack variation involves runc exec, which is used to start a process inside an existing container. This requires the attacker to know that an administrative process calls runc exec with the -cwd argument and a specific path and then replace that path with a symbolic link to the /proc/self/fd/7 file descriptor.
A third attack involves using either the runc run or the runc exec technique to overwrite binaries from the host operating system such as /bin/bash — the Linux shell. These two variations are known as attacks 3a and 3b.
“Strictly speaking, while attack 3a is the most severe from a CVSS perspective, attacks 2 and 3b are arguably more dangerous in practice because they allow for a breakout from inside a container as opposed to requiring a user execute a malicious image,” the runc maintainers said.
However, this is dependent on context. For example, in higher-level runtimes like Docker or Kubernetes anyone with the rights to start a container image can execute the exploit remotely. The attack can also be launched by using the ONBUILD feature in Dockerfiles.
While runc is probably the most popular and widely used container runtime because of its association with Docker, it is not the only container runtime available. The runc maintainers warn that they believe other runtimes are potentially vulnerable to similar attacks or don’t have sufficient protection against them.
How to mitigate the Docker runc vulnerability
In addition to the runc vulnerability, which was fixed in the newly released runc 1.1.12, McNamara also found container escape vulnerabilities in other Docker components such as BuildKit (CVE-2024-23652 and CVE-2024-23653) and a cache race condition (CVE-2024-23651).
“Look for announcements from the provider of your container build and orchestration systems regarding updates to address the fix or statements in instances where they are not impacted,” the Snyk researchers said. âThis likely means updating your Docker daemons and Kubernetes deployments, as well as any container build tools that you use in CI/CD pipelines, on build servers, and on your developers’ workstations.”
Snyk also developed two open-source tools that allow users to monitor their containers for signs of exploitation attempts. One is a runtime scanner that uses eBPF hooks to monitor for suspicious invocations of container build and running commands that match this exploit’s patterns and the other is a static scanner for Dockerfiles and images.