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
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
You can use the predefined deployment file to quickly deploy it to your
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
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
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 your
cloud 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
- 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.
Cilium is an open-source project to provide eBPF-based
networking, security, and observability for cloud-native environments such as
Kubernetes clusters and other container orchestration platforms.
We were able to block RCE by enforcing a simple policy via KubeArmor; the
policy is as follows:
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
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
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
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.