This article is more than 1 year old
Kubernetes container runtime CRI-O has make-me-root flaw
Cr8escape priv-escalation bug opens the door to cluster takeovers
A vulnerability in the container runtime engine CRI-O can be exploited by a rogue user to gain root-level access on a host.
In a Kubernetes environment powered by CRI-O, the security hole can be used by a miscreant to move through a cluster as an administrator, install malware, and cause other chaos.
CrowdStrike's threat research team discovered the privilege-escalation flaw in CRI-O version 1.19. The bug, tracked as CVE-2022-0811 and more creatively dubbed cr8escape, received a severity score of 8.8 out of 10.
CrowdStrike privately disclosed the vulnerability, and CRI-O's developers today released a fix while recommending immediate patching. Besides Kubernetes, other software and platforms that depend on or use CRI-O – these include OpenShift and Oracle Container Engine for Kubernetes – may also be vulnerable, CrowdStrike warned.
Each Kubernetes node includes a container runtime such as CRI-O. Among other tasks, the container runtime allows containerized apps to safely share each node's underlying Linux kernel and other resources. As part of this, Linux ensures that when one container alters a kernel setting, this change isn't reflected in other containers or on the host as a whole, thus keeping the containers suitably isolated from each other and the underlying platform, CrowdStrike explained.
"Some parameters are namespaced and can therefore be set in a single container without impacting the system at large," the threat researchers wrote. "Kubernetes and the container runtimes it drives allow pods to update these 'safe' kernel settings while blocking access to others."
And herein lies the security flaw: CRI-O introduced a bug that allows attackers to bypass these safeguards and set kernel parameters. "Due to the addition of sysctl support in version 1.19, [the pinns utility] will now blindly set any kernel parameters it's passed without validation," the threat researchers explained.
This means that anyone who can deploy a pod on a cluster using 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," CrowdStrike continued.
- Microsoft patches critical remote-code-exec hole in Exchange Server and others
- Microsoft patches critical remote-code-exec hole in Exchange Server and others
- Microsoft squashes OneDrive bug that caused files to linger after PC wipe
- Microsoft patches critical remote-code-exec hole in Exchange Server and others
Once they've escaped the container, gained root access to the host, and moved anywhere they want in the cluster, miscreants could perform all types of mischief.
"Invocation of CVE-2022-0811 can allow an attacker to perform a variety of actions on objectives, including execution of malware, exfiltration of data and lateral movement across pods," they wrote.
The team also noted: "Kubernetes is not necessary to invoke CVE-2022-8011. An attacker on a machine with CRI-O installed can use it to set kernel parameters all by itself."
CrowdStrike also offered remediation tips at both the Kubernetes and CRI-O level. At the Kubernetes level, the security vendor said its ideal to "use policies to block pods that contain sysctl settings with '+' or '=' in their value."
As a "less ideal" measure, the security vendor recommended using "the PodSecurityPolicy forbiddenSysctls field to block all sysctls (it's necessary to block all sysctls as the malicious setting is smuggled in a value)."
And then obviously at the CRI-O level: upgrade to a patched version of the container runtime software. CrowdStrike also suggested users "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." ®