Why Is Container Security Important

Unless you have been living under a rock somewhere, you would have heard about docker containers. Just like in 1956, the advent of the shipping containers that revolutionized freight transport, docker containers have changed the way modern software is packaged and deployed. Unlike a virtual machine,… Read More

Unless you have been living under a rock somewhere, you would have heard about docker containers. Just like in 1956, the advent of the shipping containers that revolutionized freight transport, docker containers have changed the way modern software is packaged and deployed. Unlike a virtual machine, which abstracts out the entire software including the operating system, containerized applications and their related components run on top of a single operating system. Since it doesn’t

From a security standpoint, all of this isolation is a good thing. If one container is compromised, it is almost impossible for the bad guys to cross over to another container, as the operating system has separate namespaces for each of the containers. However, is it possible for a containerized image to somehow inject malicious code into the host operating system and compromise it? This question has been nagging many security researchers and, most likely, bad guys too for quite some time. Inspired by the Capture the Flag contest in the 35th Chaos Communication Congress, Adam Iwaniuk and Borys Poplawski gained some insight that they felt could be used to compromise the “docker exec” functionality. Within a couple of months, they went on to share their findings on how to compromise a host with a malicious docker image. 

Their blog post lists the full details of their journey, including the many approaches that failed, as Linux containers are well architected for security. However, there is a small window of opportunity before the “docker exec” sets up the container image and forks into its own restricted namespace. They were finally able to strike gold by tampering with the docker-runC command during this short window.

RunC is the glue between the host and the container. As the name suggests, it runs the application in the container. It is responsible for restricting privileges to the container image and isolating its namespace. In their blog post, Adam and Borys provide the details of how to inject code — through a shared library — and corrupt the host’s copy of runC. The next time runC is executed to launch a container, it has full control of the host system and is operating with root privileges! They had the attention of the dockerized world including the maintainer of runC, Aleksai Sarai, who quickly released a patch, and CVE-2019-5736 was born.

Just like most of the modern software world, we make extensive use of containers to package and deploy our AttackIQ platform. It is only a matter of time before the bad guys discover other ways to compromise containerized images. It is imperative for us to have a comprehensive program that secures the applications in the container, the applications’ dependencies, the container development pipeline, and the infrastructure that is running these containers. It is equally, if not more, important for us to build out our Scenarios Library to include attacks of the container pipeline and run-time environments so our customers can validate their container security posture.

The startup world has taken note of this new opportunity and there are numerous new companies that are developing tools in this space. A recent Forrester report outlined the following companies broken down by their estimated revenue in this space.

Many of these technologies have comprehensive solutions that range from keeping track of CVEs for the docker component libraries and applications to monitoring the run-time execution and alerting if there are some strange processes or network behaviors of the individual containers.

We all know that today is Mother’s Day. Don’t forget to honor and celebrate your moms today and we wish a Happy Mother’s Day to your fabulous moms.