A new vulnerability in the CRI-O container runtime used by many Kubernetes installations allows a malicious user to gain root access to the host. The vulnerability was discovered by researchers from CrowdStrike and fixed soon after by the CRI-O project.
This vulnerability was discovered and reported by CrowdStrike researchers who disclosed it to CRI-O. The CRI-O project fixed the vulnerability in a patch. Dubbed "cr8escape", the bug has a score of 8.8 in the Common Vulnerability Scoring System (CVSS).
According to the CVE report:
This issue allows anyone with rights to deploy a pod on a Kubernetes cluster that uses the CRI-O runtime to achieve a container escape and arbitrary code execution as root on the cluster node, where the malicious pod was deployed
CRI-O is an open source container implementation of the Kubernetes Container Runtime Interface (CRI). It was accepted into the CNCF incubator in 2019 and is used as an alternative to Docker in some Kubernetes installations. Managed Kubernetes providers that use CRI-O as a runtime include Red Hat's OpenShift and Oracle's Cloud Native Environment. Most well-known managed services like AWS EKS, GKE and Azure AKS use either Dockershim or containerd.
Containers can set kernel parameters which are namespaced and can thus impact only that container without affecting other containers running in the same host. This is true whether the container is running inside Kubernetes or in a standalone container runtime. "Kubernetes and the container runtimes it drives allow pods to update these 'safe' kernel settings while blocking access to others" - the CrowdStrike researchers explain in their article.
The CRI-O version 1.19 introduced a vulnerability that allows a malicious user to bypass these safety measures and set arbitrary kernel parameters on the host machine. The "kernel.core_pattern" parameter could be used to run commands as root on the host. Under the hood, the CRI-O project uses the "pinns" utility to set kernel options for a pod. This was done without any validation which led to arbitrary code execution on the host.
It is noteworthy that a user must have pod deploy rights to the runtime or to the Kubernetes cluster in order to exploit this. Christophe Tafani-Dereeper, security researcher at DataDog, notes that Kubernetes clusters that don't have security measures like Pod Security Admission or Pod Security Policies enabled are at the same level of risk irrespective of this vulnerability. Pod Security Policies are, however, deprecated since Kubernetes 1.21.
Another vulnerability in the runc CLI tool that surfaced in 2019 allowed root access to the underlying host to malicious containers. Kubernetes - the platform and related tools - itself has had some vulnerabilities reported and fixed in recent years, and there has been an increasing focus on hardening guides.
