By Fei Huang
A new docker vulnerability affecting container security, CVE-2019-5736 was just announced, with some calling it a ‘Doomsday Docker Security Hole.’ This is just 2 months after the critical Kubernetes vulnerability was reported allowing attackers to take control of the api server.
From one of the runc maintainers Aleksa Sarai:
Aleksa stated that “this docker vulnerability allows a malicious container to overwrite the host runc binary and gain root level code execution on the host. The default AppArmor or SElinux policies won’t block it, but if users correctly configure the container’s user namespaces without mapping in host root, then this issue will be blocked.”
So what is runC and why this is critical? runC is the universal container runtime contributed by Docker, and it is one of the fundamental building blocks for today’s most popular container platforms. runC is created and used by Docker, Google, IBM, Red Hat, Microsoft and many other partners to create a common and standardized runtime specification. It is the core module that makes a container portable on different Linux operating systems.
With a malicious container, a hacker could potentially run any commands or create a new container as root. As a sequence in the kill chain, the hacker gains control and could move laterally. The chain typically also includes identifying sensitive data, creating communication tunnels, damaging systems, doing crypto-mining or even stealing your data silently from the backend.
For container end users, the chances are very high that your environment is vulnerable to this issue. Today popular container registries like Docker Hub have already more than 100,000 container images which are widely used by all kinds of applications world wide. It’s already been found that hackers are putting malicious code into popular container images like MongoDB, Java, MySQL etc. In the coming days or weeks your security scanner will probably be able to pick it up, scan images then report the vulnerabilities. But what about your production Kubernetes applications? How will they be protected even before vulnerabilities like this docker vulnerability are discovered?
The quick answer is to deploy a real run-time container security solution which uses a zero trust model that doesn’t rely on engineers or developers to take care of all security issues up front. A real container security solution will guard your container environment from a run-time security angle, monitoring and inspecting all the process, filesystem, and network behavior of running containers. It will be able to report and block any suspicious behavior by detecting multiple attacking vectors at run-time. It’s critical that even though you might not have a patch/fix for a critical CVE yet, the security mesh will monitor and protect your containers at run-time to make sure they only talk to the right service in right language (application protocol). This is the last line of defense against a data breach, which only a true layer 7 container security solution will offer.
With fast growing and evolving container technologies, more and more new technologies are built into container platforms, creating potential security holes. For example, adding a service mesh layer on Kubernetes through Istio or linkerd2. While these make Kubernetes more solid and more production ready, at the same time the orchestration layer has become more and more complicated, making it difficult to secure. For example, if you take a detailed look of what Istio sidecar containers will bring into the system, you will be surprised by how much more network interfaces are opened and used just by service routing. If everything including the runc, Istio, Kubernetes, Docker plugin and other system resources functioned as expected and were not vulnerable to attacks, the world would be perfect. But, we all know that’s not the truth.
Please feel free contact us if you want understand what’s the best strategy for mitigating this critical CVE and for future container security flaws.
