A vulnerability with a score of 8.8 lurks in this version and could lead to arbitrary code execution and data breaches.

A new vulnerability has been discovered in CRI-O, the container runtime engine underpinning Kubernetes.

A flaw introduced in CRI-O version 1.19 allows an attacker to bypass system safeguards and set arbitrary kernel parameters on the host. As a result of this vulnerability, 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.

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. The CVE score is 8.8 (High) and the potential impact is widespread, as many software and platforms use CRI-O by default.

The cybersecurity vendor that made the discovery, CrowdStrike, had disclosed it to Kubernetes, which has worked with CRI-O to issue a patch on GitHub. It is recommended that CRI-O users patch the vulnerability—which they have dubbed ‘cr8escape’—immediately.

For remediation at the Kubernetes level:

  • Ideally, use policies to block pods that contain sysctl settings with “+” or “=” in their value.
  • Alternatively, use the PodSecurityPolicy forbiddenSysctls field to block all sysctls (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 immediately.
  • 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)

While the vulnerability is in CRI-O, software and platforms that depend on it are also likely to be vulnerable, including: OpenShift 4+ and Oracle Container Engine for Kubernetes.