👉 Overview
👀 What ?
RunC is a lightweight, portable container runtime. It's the underlying technology that powers many of the services we use today. A privilege escalation vulnerability in RunC allows a malicious container to overwrite the host RunC binary and thus gain root-level code execution on the host machine.
🧐 Why ?
Understanding this topic is crucial because containers are becoming increasingly common in today's technological landscape. They provide an easy and efficient way to package and distribute applications, but they also come with their own set of security challenges. This particular vulnerability could potentially allow an attacker to gain complete control over a host machine, making it a serious threat to any system running vulnerable versions of RunC.
⛏️ How ?
To exploit this vulnerability, an attacker would first need to gain control of a container running on a vulnerable host machine. They could then replace the RunC binary on the host with a malicious version, which would be run the next time a container is started. This would give the attacker root-level access to the host machine. To protect against this, users should ensure they are running a patched version of RunC that is not vulnerable to this issue.
⏳ When ?
The RunC privilege escalation vulnerability was first discovered and reported by researchers at OpenWall in early 2019. It was quickly patched, but not before it had been exploited in the wild.
⚙️ Technical Explanations
The RunC privilege escalation vulnerability is a critical security issue that was discovered in 2019. The underlying cause of this vulnerability is a flaw in how RunC, a lightweight and portable container runtime, handles file descriptors.
In more technical terms, the issue arises specifically due to the improper handling of file descriptors related to /proc/self/exe. In a Linux system, /proc/self/exe is a symbolic link that points to the executable file of the current running process. A flaw in RunC's handling of these file descriptors can allow a malicious container to replace the host's RunC binary.
When a container starts up, it uses the host's RunC binary. If a malicious container overwrites this binary, it can result in the execution of malicious code at the root level the next time any container is started. This effectively gives the attacker root-level access to the host machine, posing a significant security risk.
To mitigate this vulnerability, a patch was introduced which added additional checks to ensure file descriptors are handled properly. This prevents the malicious overwrite of the RunC binary. Users are strongly advised to make sure they are running a version of RunC that includes this patch to protect their systems from potential exploitation.
Here is a hypothetical example to illustrate the process:
Step 1 - Control a container: First, an attacker might gain control of a container running on a vulnerable host machine. This could be done through a variety of methods, such as exploiting another vulnerability in the application running inside the container.
Step 2 - Replace the RunC binary: Once the attacker has control of the container, they could then replace the RunC binary on the host with a malicious version. This could be achieved with a command like:
cp /malicious/runc /proc/self/exe
In this command, /malicious/runc is the path to the malicious RunC binary that the attacker has prepared, and /proc/self/exe is the symbolic link that points to the container's current running executable - the host's RunC binary.
Step 3 - Execute the malicious binary: When a new container is started on the host, it will use the malicious RunC binary, executing the malicious code with root-level privileges on the host machine.
To protect against this vulnerability, users should ensure they're running a patched version of RunC. The patch adds additional checks to ensure file descriptors are handled properly, preventing the overwrite of the RunC binary. The version can be checked with the command:
runc --version
If the version is earlier than 1.0-rc93, then it is vulnerable and should be updated.