Linux administrators with the CRI-O container runtime for Kubernetes in their environments are urged to immediately install the latest patch to close a serious vulnerability.
This comes after security researchers at CrowdStrike discovered the vulnerability (tracked as CVE-2022-0811) in CRI-O.
Dubbed “cr8escape,” it could allow an attacker to escape from a Kubernetes container, gain root access to the host and be able to move anywhere in the cluster. That would allow the attacker to do anything from executing malware to copying data and moving laterally across pods.
Note that Kubernetes, an open-source container orchestration system for automating software deployment, scaling, and management, is not necessary to invoke CVE-2022-8011, says CrowdStrike. An attacker on a machine with CRI-O installed can use it to set kernel parameters all by itself.
CRI-O is an implementation of the Kubernetes Container Runtime Interface to enable using OCI (Open Container Initiative) compatible runtimes. CRI-O developers say it is a lightweight alternative to using Docker as the runtime for Kubernetes that allows Kubernetes to use any OCI-compliant runtime as the container runtime for running pods.
According to CrowdStrike, Kubernetes uses a container runtime like CRI-O or Docker to safely share each node’s kernel and resources with the various containerized applications running on it. The Linux kernel accepts runtime parameters that control its behavior. Some parameters are namespaced and can therefore be set in a single container without impacting the system at large. Kubernetes and the container runtimes it drives allow pods to update these “safe” kernel settings while blocking access to others, CrrowdStrike’s blog explained.
But a flaw introduced in CRI-O version 1.19 allows an attacker to bypass these safeguards and set arbitrary kernel parameters on the host, it says. As a result of the issue described in CVE-2022-0811, anyone with rights to deploy a pod on a Kubernetes cluster that uses the CRI-O runtime can abuse the “kernel.core_pattern” parameter to achieve container escape and arbitrary code execution as root on any node in the cluster.
The report says that while the vulnerability is in CRI-O, software and platforms that depend on it are also likely to be vulnerable, including Red Hat OpenShift 4+ and Oracle Container Engine for Kubernetes.
At the Kubernetes level, administrators should, if possible, use policies to block pods that contain sysctl settings with “+” or “=” in their value. Otherwise use the PodSecurityPolicy forbiddenSysctls field to block all sysctls (it’s necessary to block all sysctls as the malicious setting is smuggled in a value).
At the CRI-O level, in addition to upgrading to a patched version of CRI-O, administrators should set pinns_path in crio.conf to point to a pinns wrapper that strips the “-s” option before invoking the real pinns. This will prevent pods from updating any kernel parameters, including sensitive ones. Pinns, typically found at /usr/bin/pinns, is the utility CRI-O uses to set kernel parameters.