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?
LIVING IN A POST-CONTAINER WORLD
Free: Brand new Serverless Architecture Whitepaper
Stay on top of the latest trends with the help of our Serverless Architecture Whitepaper. Get deep insights on serverless platforms, cloud-native architecture, cloud services, the Kubernetes ecosystem (Knative, Istio etc.) and much more!
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 rootless.
Researchers Adam Iwaniuk and Borys Popławski discovered the runC security vulnerability.
An e-mail from Aleksa Sarai, Senior Software Engineer and developer at the open source software company SUSE, describes the runc Container breakout.
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.
SEE ALSO: The future of open source: An increased focus on security and performance
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“.
Patching up
In response, Docker quickly released version 18.09.02.
This security flaw had the potential to affect countless users. Google Cloud Platform, RedHat, and AWS posted bulletins about the security issue detailing how to update the patch.
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.
Rami Sass
SEE ALSO: Sail smoothly with a simple management UI for Docker
Security concerns
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!
The post RunC container vulnerability: What makes it so dangerous? appeared first on JAXenter.
Source : JAXenter
