CVE-2022-0811 in CRI-O
Summary
by MITRE • 03/16/2022
A flaw was found in CRI-O in the way it set kernel options for a pod. This issue allows anyone with rights to deploy a pod on a Kubernetes cluster that uses the CRI-O runtime to achieve a container escape and arbitrary code execution as root on the cluster node, where the malicious pod was deployed.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 03/19/2022
The vulnerability identified as CVE-2022-0811 represents a critical container escape flaw within the CRI-O container runtime implementation. This issue stems from improper handling of kernel options during pod creation processes, creating a pathway for privilege escalation that can compromise entire cluster nodes. The flaw exists in how CRI-O manages kernel parameters when initializing pods, specifically failing to properly isolate or restrict kernel capabilities that should remain restricted to the host system level.
The technical exploitation of this vulnerability occurs through the manipulation of kernel options during pod deployment. When a malicious actor gains the ability to create pods within a Kubernetes cluster utilizing CRI-O as the container runtime, they can craft specific pod configurations that leverage the improper kernel option handling. This flaw allows attackers to escalate privileges from container context to root access on the underlying node, effectively breaking the isolation boundaries that containerization is designed to maintain. The vulnerability operates at the intersection of container runtime security and kernel-level privilege management, where inadequate sandboxing mechanisms enable direct access to host kernel functionalities.
From an operational impact perspective, this vulnerability fundamentally undermines the security model of Kubernetes clusters using CRI-O. A successful exploitation results in complete compromise of the affected node, enabling attackers to access all resources, data, and processes running on that host system. The implications extend beyond individual node compromise, as attackers can leverage the elevated privileges to pivot within the cluster, potentially accessing other nodes, persistent volumes, or even cluster-wide resources. This vulnerability directly impacts the principle of least privilege and container isolation that Kubernetes relies upon for security assurance.
The vulnerability aligns with CWE-276, which addresses improper privilege management, and maps to ATT&CK techniques including T1068 for exploit for privilege escalation and T1565 for data manipulation. Organizations should immediately update their CRI-O installations to versions that address this flaw, implement strict pod security policies, and consider additional runtime monitoring to detect anomalous kernel parameter configurations. Network segmentation and RBAC controls should be reviewed to limit the potential blast radius of such compromises, while also ensuring that only trusted entities have the ability to deploy pods within the cluster. Regular security audits of container runtime configurations and kernel parameter management should be implemented as part of comprehensive security hygiene practices.