CVE-2022–0185: What is it, how to identify, and it’s impact on Kubernetes Workloads
Discovery of CVE-2022-0185 Vulnerability
Last week, researchers Jamie Hill-Daniel and William Liu discovered & disclosed a vulnerability in Linux Kernel.
It’s assigned a CVE ID of CVE-2022-0185. And is rated as High Severity. This got introduced to Linux Kernel as part of version 5.1-rc1 in March 2019, almost 3 years ago.
Impact of Linux Vulnerability
This vulnerability is related to a heap-based buffer overflow in the “File System Context” Linux kernel component. This can lead to multiple attacks.
An attacker can use this flaw to attack via Privilege Escalation to root, Escape to Host from the containers environment, Denial-of-Service to crash the system, an out-of-bounds write, and arbitrary code execution.
An attacker can change the values in Kernel memory and access any process running on the same host. It can be used by a local user to escalate privileges.
In order to exploit, the attacker needs to use an unprivileged namespace or use unshare to enter a namespace with the CAP_SYS_ADMIN permission. It’s neither a default setting nor a common practice on Docker. This vulnerability is applicable for containers initiated with a --privileged flag.
Also, the unshare command is blocked by Docker’s seccomp filter by default, so running the command isn’t permitted by default.
However, seccomp the filter is disabled by default when Docker or other container platforms are used in Kubernetes Clusters. So, unshare the command is not blocked.
In order to exploit the vulnerability, the attacker needs to be able to run code in a container with CAP_SYS_ADMIN privileges.
It can be seen in the demo below.
Identification
This is a useful repo shared by the Crusaders-of-Rust team for identification of the issue. A very detailed write-up is here.
You can check the Node & Kernel Version used by running the following command:
kubectl get nodes -o jsonpath='{range .items[*]}Node - {.metadata.name}{"\n"}Kernel Version: {.status.nodeInfo.kernelVersion}{end}'
Mitigation
A fix was released on the 18th as part of Kernel 5.16.2 and there have been several patches released to address this issue. These patches are released by Linux Kernel and other major distribution maintainers.
Here are the patches:
- https://access.redhat.com/security/cve/CVE-2022-0185
- https://ubuntu.com/security/CVE-2022-0185
- https://security-tracker.debian.org/tracker/CVE-2022-0185
It’s highly recommended to download and install the latest Kernel version. This applies to Linux users and administrators.
Upgrading the Linux kernel to version 5.16.2 or later addresses the problem. However, the update is not available for all distributions yet.
If patching is not an option, disable unprivileged user namespaces.
On Ubuntu, use this command to disable unprivileged namespaces:
sysctl -w kernel.unprivileged_userns_clone=0
For RedHat, users without containerized deployments disable user namespaces:
echo "user.max_user_namespaces=0" > /etc/sysctl.d/userns.confsysctl -p /etc/sysctl.d/userns.conf
If unprivileged containers are needed, in that case seccomp the filter should block the unshare call.
For individual workloads, Kubernetes has a detailed tutorial on how to add seccomp to the securityContext field definition. Check this out here.
How can Cloudanix help?
Cloudanix helps you to improve your Cloud Security. Our platform offers CSPM, CIEM, and CWPP (Container Vulnerability) all in one – so your Kubernetes-based workloads running in any cloud or bare-metal can be secure.