CVE-2022-0492 – Privilege Escalation and Container Escape Vulnerability and its impact on Kubernetes

On March 4th, a new privilege escalation vulnerability (CVE-2022-0492) in the Linux kernel was published. It has the potential to allow container escape and take control over the entire node on which the container runs.

All the CSPs and Linux distribution providers have issued patches to close this vulnerability. Unfortunately, there is no unified kernel version numbering across these platforms and some of them allow to apply a patch without changing the kernel version number. 

However, applying these patches and upgrading the base images may take months, during which your platform may remain susceptible to the potential attack.

Impact on Kubernetes

Container escape is the most fundamental potential problem for Kubernetes platforms where physical compute nodes are shared between many unrelated containers. If exploited, malicious software may take control over the node, obtain sensitive data from other containers on this node, and even access network APIs assuming the identities of the other containers.

If one/some of the PODs on the exploited node has a Kubernetes Service Account token with sufficient privileges, attackers may use it to obtain sensitive information about the cluster or even add/modify cluster workloads, gain persistency and inject more malicious code into the system.

Running on the node level, malicious code may bypass network policies and communicate with the outside world more freely than the isolated container. 

Is your cluster vulnerable?

Until you upgraded the base kernel image to the fixed version or applied a specific temporary patch, your node is vulnerable.

However, to exploit this vulnerability, attacks must run their malicious code in your environment with root privileges (at least local, in-container, root) or CAP_DAC_OVERRIDE capability. So, they either should break into one of the suitable containers or trick you into the execution of a rough image with such malicious code.

Therefore, if you follow best practices and configure your Kubernetes deployments to use recommended security measures and the least privileged principle, you can mitigate the problem until the kernel upgrade. It is important to note that security configurations in Kubernetes are applicable to each individual POD rather than a node. Therefore, these configurations must be applied to every POD that may potentially contain a malicious code trying to escape its container isolation.

Mitigation and verification

Kubescape has developed a dedicated control – C-0086- in the ARMOBest framework verifying the presence of necessary security hardening configurations preventing the exploitation of this CVE-2022-0492.

Note that if a POD is deliberately configured to run as privileged or has CAP_SYS_ADMIN capabilities, it will not fail the CVE-2022-0492 control because it is allowed by design to bypass the isolation.

Enabling SELinux or AppArmor will block the exploitation of the CVE. Our verification algorithm assumes that container runtime is configured to use cgroup version 1 implementation by default.

If you see many resources failing this control, you will most likes see the same resources failing “non-root” and “allow privilege escalation” controls which emphasize the importance of the best security practices in general and the least privilege principle in particular.

Please install or update to the latest Kubescape version from GitHub, or via the following command:

curl -s https://raw.githubusercontent.com/armosec/kubescape/master/install.sh | /bin/bash

To learn more: https://hub.armosec.io/docs/welcome-to-kubescape-user-hub