HerrBullermann - Fotolia
One of the key concepts of containers -- that all operations are contained within the isolated environment -- has been challenged recently with vulnerability CVE-2016-9962, known as a container escape vulnerability.
In this vulnerability, an error in the method that containers use to execute commands (with the built-in code known as the opencontainer runc), allows a malicious user with access to the container to escape the restricted environment and access the underlying host server.
The basic premise is that a malicious process created inside the container is able to hijack a legitimate command run by an administrator inside the container. The timing of the exploit must be very precise, running the malicious process at just the right time in a small window of opportunity. If timed correctly, the malicious process can access files on the host server, and then use this to perform a full container escape.
The most likely scenario is that the attacker uses a process within the container to make it behave strangely enough to encourage investigation from an administrator. Once the administrator runs a process to investigate the problem, the malicious process activates and achieves the escape.
The impact of a container escape is similar to escapes from virtual machines, as both allow access to the underlying server. This can be a significant issue in infrastructure as a service (IaaS) environments because access to the underlying host server, especially if achieved with root privileges, could allow the data of other cloud users to be compromised.
Proof of concepts have been shown for container escape vulnerabilities being used to break out of Amazon Elastic Compute Cloud containers running Docker (these vulnerabilities were later patched).
Vendors have listed the vulnerability with different risk levels; for example, Amazon rates it as important, its second tier of classification, whereas Red Hat only classify it as moderate. Docker itself only refers to the vulnerability as minor. This is largely based on how the individual vendors calculate their risk ratings, and their understanding of how the vulnerability can be exploited in their particular software or operating system.
The vulnerability has since been patched (check that your Docker version is at least 1.12.6; if not, run the command yum update docker), but this is not the first container escape vulnerability.
With containers being a relatively new concept -- at least in their adoption by enterprises -- research into the impact of Linux vulnerabilities is not always extended to how they affect containers. This is likely to change as container usage increases, both within the organization's own environment and through the use of IaaS.
If you use IaaS platforms for your infrastructure, it's important to know where your responsibility lies in regards to keeping the software installed on your instances up to date. IaaS providers tend to use a shared responsibility model, where keeping the container versions up to date is likely to be your responsibility.
Learn more about containers and virtualization
Find out what you need to know about containers in the cloud
Discover how to secure enterprise container stacks