How to Protect from Common Vulnerabilities and Exposures CVE-2022-0185
Introduction People consider Linux the most secure operating system, as it is open-source. Even with all its might, vulnerabilities creep in the shadow, ready to strike. In this blog, we’ll be taking a look at an infamous heap overflow vulnerability discovered in 2022. The growth of the Kubernetes and containers increased exponentially than the previous […]
Reading Time: 4 minutes
People consider Linux the most secure operating system, as it is open-source. Even with all its might, vulnerabilities creep in the shadow, ready to strike. In this blog, we’ll be taking a look at an infamous heap overflow vulnerability discovered in 2022. The growth of the Kubernetes and containers increased exponentially than the previous year. It led to finding a new Linux Kernel Vulnerability, dubbed CVE-2022-0185, which was introduced to the build three years ago and went undetected till 2022. Credits to William Liu and Jamie Hill-Daniel for discovering the vulnerability CVE-2022-0185.
Before we get into details, let’s recall two basic security principles, the Least Privilege Model, which states “components should only have access rights to only what are strictly required to do their jobs, thereby denying any possibility of privilege escalation” and the Zero-Trust Model, following the principle “never trust, always verify”.
Who is Vulnerable to this CVE?
Consider a running cluster with a Linux kernel version between 5.1 – 5.15 and pods deployed with sys_admin capabilities. With the heap overflow attack, an attacker abuses the functionality which lies on legacy_parse_param leading to an escape from container environments and elevating privileges.
You can check your kubernetes kernel version using the following command
How does this work?
To better understand the vulnerability and how it is working, let’s go ahead and replicate it in a controlled environment.
We will create a new Kubernetes cluster with Release channel as Rapid Channel and Version as 1.22.3-gke.700, leaving the remaining as default.gcloud
container clusters create “cve-demo” –zone “us-central1-c” –cluster-version “1.22.3-gke.700”; –release-channel “rapid”
Now we have our cluster with Kernel version <5.16 ready. It’s time to deploy an ubuntu pod and test the exploit.
For this, we have created an ubuntu image with
lsof pre-installed into it. The image also runs as a non-root user. To ensure that the pod doesn’t go into a completed state, we added the command
You can use the predefined deployment file to quickly deploy it to your environment.
With this, the initial setup is completed. It’s time to execute the exploit and see if we can get a root shell poped using privilege escalation.
To explain the exploit, let’s take a look at the root cause of this CVE, the offending function
Well, how can we create an overflow from this scenario? You can see the bound check to prevent overflows:
if (len > PAGE_SIZE –
2 – size)
“VFS: Legacy: Cumulative options too large”;
While this bound check will suffice for most cases, if your size is 4095 bytes or greater, an integer underflow will occur as size, in this case, is an unsigned int. Hence, trigger the underflow there, and you will get infinite heap overflow.
This bug popped up since 5.1-rc1. It’s important to note that you need the CAP_SYS_ADMIN capability to trigger it, but the permission only needs to be granted in the CURRENT NAMESPACE. Most unprivileged users can unshare(CLONE_NEWNS|CLONE_NEWUSER) (the equivalent of the command unshare -Urm) to enter a namespace with the CAP_SYS_ADMIN permission and abuse the bug from there; this is what makes this such a dangerous vulnerability.
Let’s see this in action.
To replicate the issue, we will execute it into our deployed
kubectl exec -it $(kubectl get po -lapp=ubuntu-pod -o name |
cut -d / -f2) — bash
Alright! Now we will get the exploit code and make it executable.
&& chmod +x exploit
Code block 2
The exploit will run for a moment, does its magic, and present you with a root shell.
As you can see, we went from
id 1000 to
Disabling the vulnerability with open-source AccuKnox products
KubeArmor is open-source software that enables you to protect yourcloud workload at run-time.
The problem that KubeArmor solves is that it can prevent cloud workloads from executing malicious activity at run-time. Malicious activity can be any activity that the workload was not designed for or is not supposed to do. Given a policy, KubeArmor can restrict the following types of behavior on your cloud workloads:
- File access – allow/deny specific paths
- Allow / deny Process execution / forking
- Allow / Deny Establish network connections
- Allow / Deny workloads to request other capabilities with the host os. Such
capabilities can enable additional types of malicious behavior.
We were able to block RCE by enforcing a simple policy via KubeArmor; the policy is as follows:
Cloud workload at runtime
The Policy: In-action
kubectl apply -f
Once you apply the policy and execute the exploit from the container, you’ll get an error message, and the exploit will exit.
./exploit [*] Spraying kmalloc-32 [*] Opening ext4 filesystem fsopen: Remember to unshare
Checking the policy logs on KubeArmor
To check how to do it, kindly go through our help section
Blocked Log Created by KubeArmor
KubeArmour code block
Even though writing KubeArmor and CIlium (System and Network) policies is not a big challenge, AccuKnox opensource has simplified one step further by introducing a new CLI tool for Auto Discovered Policies. The Auto-Discovery module helps users identify the flow and generate policies based on it.
Discovering policies has never been better with Auto Discovery. In two simple commands, you can set up and generate policies without trouble.
To check how to do it, kindly go through our help section.
In mere seconds after installing Auto DIscovery, it generated 10 Cilium policies and 9 KubeArmor policies.
These features by AccuKnox open-source makes sure that all the necessary policies to secure your workload are generated and ready to be used in a single click.
Accuknox’s policy templates repository
Accuknox’s policy templates is an open-source repo that contains a wide range of attack prevention techniques, including MITRE and hardening techniques for your workloads. Please visit GitHub – kubearmor/policy-templates: Community curated list of System and Network policy templates for the KubeArmor and Cilium to download and apply policy templates.
Even though zero-day exploits are more brutal to avoid and protect from, with AccuKnox opensource tools, you can prevent your workloads from possible threats and vulnerabilities until you can get a permanent solution from the vendor.
Using AccuKnox open-source tools, an organization can effectively protect against all sorts of accidental developer-introduced vulnerabilities and zero-day vulnerabilities even without having downtime or risky half-baked patches.
Now you can protect your workloads in minutes using AccuKnox, it is available to protect your Kubernetes and other cloud workloads using Kernel Native Primitives such as AppArmor, SELinux, and eBPF.
Let us know if you are seeking additional guidance in planning your cloud security program.
Must read articles
- Zero Trust (ZT) – The Future of Cloud Security
- Zero Trust (ZT) Architecture, Framework and Model
- Cloud Security Governance, Risk and Compliance (GRC)
- How to Pick the Right CNAPP (Cloud Native Application Protection Platform) Vendor
- What is Driving the Need for CSPM (Cloud Security Posture Management)
- Agent vs Agentless Multi Cloud Security
You cannot secure what you cannot see.
Your most sensitive information is stored on endpoints and in the cloud. Protect what is most important from cyberattacks. Real-time autonomous protection for your network's edges.