A report by CrowdStrike reveals that an extreme weakness affecting the CRI-O container engine for Kubernetes could be utilized to break free from the container and gain root entry to the host.
The CrowdStrike’s threat research team uncovered that lack of proper authentication for kernel parameters passed to the pinns utility caused the exposure to the bug tracked as CVE-2022-0811 and dubbed creatively as cr8escape.
The high severity flaw in Argo CD is information leak risk and this loophole has been known to the development team since 2019 when an anti-path-traversal mechanism was added to the Argo CD, although the vulnerability exists from a control error. Argo CD is an open-source tool for Kubernetes used to monitor running applications and compare their live state. The path for this vulnerability was included in the Argo CD releases v2.3.0, v2.2.4, and v2.1.9. Argo CD users are advised to update a patched version of the platform immediately.
This security vacuum was set in motion in CRI-O version 1.19 when sysctl support was attached to the container engine. The cr8escape bug which received a severity score of 7.7 out of 10 can be utilized by a rogue user to infiltrate a cluster as an administrator and install a virus and other malware. The security flaw allows an attacker to exfiltrate data and gain lateral movement across pods. Exploitation requires rights to deploy a pod on a Kubernetes cluster using the CRI-O runtime.
The CVE-022-0811 is a path traversal bug that allows an attacker to load a Kubernetes Helm Chart YAML file and gain access to another application’s data. Helm charts are YAML files containing different fields that embed resources and configurations required for application deployment.
The CRI-O explains that an attacker must have permissions to create or update applications and also knows or needs to guess “the full path to a file containing valid YAML” before they can exploit the vulnerability. Creating a malicious Helm chart to consume that YAML as values files can help the attacker gain access to data they would otherwise have no access to. The impact of this security breach becomes critical if confidential and sensitive data exists in the environment.
As reported by CrowdStrike in its published proof-of-concept code focusing on the flaw, the consequences of this vulnerability in comparison to the broad and default use of CRI-O by many platforms is quite widespread. To prevent probable attacks, CrowdStrike recommends immediate updates of CRI-O by all users.
After the disclosure of the vulnerability by CrowdStrike, CRI-O’s developers resolved the flaw with the release of CRI-O versions 1.22.3, 1.21.6, 1.20.7, and 1.19.6, all of which contain protection and are a fix to a critical security vulnerability. CrowdStrike warns that other software platforms that use or depend on CRI-O including OpenShift and Oracle Container Engine for Kubernetes may also be vulnerable.
A point to note is that “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 remedy tips at both the Kubernetes and CRI-O levels include;
- 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.”
- Although not recommended, a downgrade to CRI-O version 1.18 or earlier version could also prevent exploitation.
Source : HackerCombat