RunC container vulnerability: What makes it so dangerous?
Were you affected by the runC container breakout? Make sure your containers are all patched up and running safely and securely. When it comes to using containers, ensuring security should be everyone’s number one priority. What makes container vulnerabilities so dangerous?
With news of the recent runC vulnerability, we should remind ourselves that container security is serious business. The security hole affected only privileged containers and Steven J. Vaughan-Nichols used the evocative phrase “Doomsday Docker security hole” when reporting in his article for ZDNet.
So, why was this such a serious threat?
Just the facts
First of all, what is runC? It is a command-line tool for spawning and running containers according to the OCI specification. It has the ability with run containers without root privileges using
Researchers Adam Iwaniuk and Borys Popławski discovered the runC security vulnerability.
He wrote: “The vulnerability allows a malicious container to (with minimal user interaction) overwrite the host runC binary and thus gain root-level code execution on the host. The level of user interaction is being able to run any command (it doesn’t matter if the command is not attacker-controlled) as root within a container in either of these contexts:
* Creating a new container using an attacker-controlled image.
* Attaching (docker exec) into an existing container which the attacker had previous write access to.”
Sarai included a patch to fix the issue as well as lists for future security vulnerability announcements and instructions on how to become a member of the Open Containers Initiative to help report future security issues.
Roughly 3,800 Docker daemons were exposed, primarily in The United States and China.
You can read more about what these two researchers found and the timeline of their tasks on their blog post “CVE-2019-5736: Escape from Docker and Kubernetes containers to root on host“.
In response, Docker quickly released version 18.09.02.
We spoke to Rami Sass, the CEO of WhiteSource about this recent security hole. He had this to say:
In general what makes vulnerabilities so dangerous is that everyone knows about them. Hackers have access to the exact same information as security professionals and can exploit the vulnerability in any instance of the software that hasn’t been patched. runC is a special case because the vulnerability isn’t in any one container, but in container host itself. This makes it possible for a hacker to exploit not just one particular container, as is usually the case, but any of the thousands of containers within Docker, Kubernetes or any of the other impacted systems. It’s crucial for any company running containers to patch runC immediately as it leaves every one of their containers vulnerable to exploitation.
When it comes to open source software, vulnerabilities are potentially devastating.
In order to secure the issue, you must go back through the software’s code. This is often written years ago by someone else. It makes mitigating security vulnerabilities difficult and time-sensitive. (And is also why embargoes on security holes are important to keep nefarious hackers from learning about the info.)
The more hands you have on board, the more problems can occur with the code. However, this also has the flip side of having more eyes on the code to search for potential vulnerabilities.
A recent article by Jane Silber about the future of open source stated, “As the implications of security vulnerabilities and breaches increase, there will be even more focus on ensuring the security of open source code (and software in general).”
While unlikely to affect a properly configured system, the runC security hole should remind everyone to take their security seriously.
Don’t run unverified container base images. Don’t give root privileges to untrustworthy sources. And most of all, patch security updates as soon as they’re available!