A serious new vulnerability lets an attacker escape from a Kubernetes container and gain root access to the host. Allocated CVE-2021-0811 and reported by CrowdStrike, the CVSS 8.8 bug is in CRI-O, a container runtime engine and alternative to containerd or Docker that many Kubernetes users rely on to share each node’s kernel and resources with the various containerised applications running on it. The bug was introduced in CRI-O version 1.19.
CRI-O was contributed to the Cloud Native Computing Foundation (CNCF) by Red Hat -- its original developer -- in 2016. It has maintainers from Intel, SUSE and others. CrowdStrike said: "The potential impact is widespread, as many software and platforms use CRI-O by default. It is recommended that CRI-O users patch immediately."
CrowdStrike (dubbing it "cr8escape") has published a detailed proof-of-concept (POC) of exploitation.
(Red Hat OpenShift is among the products that defaults to its use, including across multiple cloud offerings like Amazon Red Hat OpenShift, Azure Red Hat OpenShift. Oracle Container Engine for Kubernetes is also affected, CrowdStrike said. Version 1.22.3 is patched. To see if a host is affected, admins can run crio —version.)
Follow The Stack on LinkedIn
For remediation, at the Kubernetes level, CrowdStrike said that admins should:
- Ideal: Use policies to block pods that contain sysctl settings with “+” or “=” in their value.
- Less ideal alternative: 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:
- Upgrade to a patched version of CRI-O.
- 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.
- Downgrade to CRI-O version 1.18 or earlier. (Not recommended in most cases.)
There has been a slow but steady rise in the number of reported threat vectors in Kubernetes. In August 2021 security researchers at PaloAlto’s Unit 42 said they have identified a “heavily obfuscated” Kubernetes malware that targets clusters after escaping Windows containers. Dubbing it Siloscape, they said its main purpose is to “open a backdoor into poorly configured Kubernetes clusters in order to run malicious containers.”
Strikingly, security researcher Daniel Prizmant says he managed to gain access to the threat actor’s C2 servers to pull detail on its techniques, despite them using the Tor proxy and an .onion domain to connect. He was spotted and kicked out after two minutes, but not before pulling some valuable intelligence on the campaign.
