CVE-2022-23648: Kubernetes Container Escape Using Containerd CRI Plugin and Mitigation
CVE-2022-23648, reported by Google’s Project Zero in November 2021, is a Kubernetes runtime vulnerability found in Containerd, a popular Kubernetes runtime. It lies in Containerd’s CRI plugin that handles OCI image specs containing “Volumes.” The attacker can add Volume containing path traversal to the image and use it to copy arbitrary files from the host to container mounted path.
The vulnerability was reported by Felix Wilhelm on Nov. 22, 2021, and a patch was released with 1.6.1, 1.5.1 and 1.4.13 versions of Containerd on March 2, 2022.
Technical Analysis
Let’s take a closer look at how the vulnerability resides in an unexpected layer of the container ecosystem and can result in container escape in your Kubernetes cluster.
Understanding OCI Image Specifications
There are two specifications for a container image defined by Open Container Initiative (OCI). These standards were first made available by Docker and then developed by the community.
- Image specifications (image-spec). This specification defines how a container image should be packed and various components of the image, primarily image manifest, index and layout. This is where the image file system blob resides.
- Runtime specifications (runtime-spec). This is the configuration required to run the image as a container.
When a runtime like Containerd needs to start a container with an image, it converts the given image configuration blob to a runtime configuration blob. Here Containerd’s CRI plugin fails to validate paths in the Config.Volumes field before being used in the runtime field mounts. Containerd further copies the data to those mount paths. It is possible to look at the Config.Volume field from the OCI configuration blob with tools like buildah, as shown below in Figure 1 in addition to build steps for the image.
Figure 1. Build vulnerable image
Containerd’s Handling of Volume
The vulnerability resides in the following Containerd code, as shown below in Figure 2, where an attacker-controlled volume path is used as a source in the copyExistingContents function. This function copies the files from the attacker-controlled volume path to a temporary folder that is later mounted inside a container. At this point, an attacker just needs to use path traversal to trick the copyExistingContents function into copying arbitrary files from the host filesystem.
Figure 2. Vulnerable Containerd code #114 (https://github.com/containerd/containerd/blob/v1.6.0/pkg/cri/opts/container.go#L116)
The following is the simple attacker pod that uses our proof-of-concept image shown in Figure 1. Once this pod is created on the cluster, you can see the files from the host are copied to the container filesystem on a mounted path, as shown in Figures 3 and 4.
In this attack, without the use of actual Kubernetes volumes, an attacker with pod creation privileges on the cluster is able to read arbitrary files from the Kubernetes node, resulting in a container escape.
Figure 3. Attacker pod
Figure 4. Host files copied to the container filesystem
Mitigation
CrowdStrike recommends upgrading to the latest version of Containerd to mitigate this issue. A patch was released with 1.6.1, 1.5.1 and 1.4.13 versions of Containerd.
In case patching is not possible, the CrowdStrike Falcon®® platform’s image scanning protects customers from this vulnerability by identifying the image blob configuration with path traversal in a Volume path, as shown in Figure 5. Customers can also stop malicious images from being deployed to the cluster.
CrowdStrike Falcon® Horizon™ cloud security posture management (CSPM) implements CIS benchmarks to identify any indicators of misconfiguration (IOMs) in your clusters and uncover a weakness in cloud environment. At the same time, CrowdStrike Falcon® Cloud Workload Protection (CWP) prevents and detects malicious activity — including by eCrime and nation-state adversaries — in real time.
Figure 5. CrowdStrike Falcon® detecting path traversal in image blob Volume configuration
Conclusion
Kubernetes is composed of a number of software layers, and any misconfiguration or security issue at any layer can be used by an attacker to gain necessary privileges and take over the cluster. As discussed, CVE-2022-23648 is one more example of the ongoing weakness in container runtime being used for Kubernetes container escape. DevOps practitioners need to be on top of such issues and keep the environment up-to-date when patches are available.
Securing containers need not be an overly complex task. Using the Falcon platform, you can easily identify security issues in your environment in real time. You can use built-in Kubernetes features and implement best practices to keep your container environment safe. For enhanced security, you can use integrated container security products, such as CrowdStrike Falcon® Cloud Workload Protection, that can protect your Kubernetes environment seamlessly.
CrowdStrike strives to support organizations that allow their users to stay ahead of the curve and remain fully protected from adversaries and breaches.
Additional Resources
- Learn how you can stop cloud breaches with CrowdStrike unified cloud security posture management and breach prevention for multi-cloud and hybrid environments — all in one lightweight platform.
- Learn more about how Falcon Cloud Workload Protection enables organizations to build, run and secure cloud-native applications with speed and confidence
- See if a managed solution is right for you. Find out about Falcon Cloud Workload Protection Complete: Managed Detection and Response for Cloud Workloads.
