Risks of container escape vulnerabilities and how to counter them
Container escape vulnerabilities create new challenges for security and risk management teams. Learn more about container escapes and how to prevent exploitation.
A serious vulnerability was disclosed in runC, the primary runtime used to implement container services, including Docker, containerd and similar Linux-based container engines. The vulnerability was dubbed runcescape and tracked as CVE-2019-5736, beginning in February 2019. It enabled an attacker with access to a container to escape from it and gain root access on the host server. The container escape vulnerability could be triggered through an existing container compromise or by introduction of a new, malicious container image.
Exploitation of this vulnerability is not blocked by the default AppArmor or Security-Enhanced Linux (SELinux) policies on some Linux distributions, like Fedora. However, it is blocked by correct use of user namespaces, where the host root isn't mapped inside the container's user namespace. In other words, the underlying host of the container is not exposing the root file system to the container image. Additionally, the attack was not possible on systems that had the SELinux security mechanism enabled and in enforcing mode, such as Red Hat Enterprise Linux or Red Hat OpenShift.
This is not the first time infosec professionals have seen container escape vulnerabilities in the wild that could enable a malicious user to execute code on the underlying host that operates the container. In late 2016, CVE-2016-9962 was announced. This container escape vulnerability also involved the runC runtime manipulating host services, which could lead to escape or other privileged command execution outcomes for attackers with access to containers or images.
Countering cloud escape vulnerabilities
What do cloud escapes mean for security and risk management teams that need to better understand the likelihood of these flaws affecting their organization's cloud services?
This is not the first time infosec professionals have seen container escape vulnerabilities in the wild that could enable a malicious user to execute code on the underlying host that operates the container.
First, it is important to qualify the types of cloud services in use. In IaaS container deployments, organizations may choose to run the entire container stack, including container images and the underlying hosts that operate them. In these cases, the responsibility for patches or updates, as well as configuration of the container runtime components, may fall on the organization. This is due to the nature of the shared responsibility model. In PaaS environments -- or in IaaS scenarios that run serverless microservices applications -- however, the entire underlying container host and runtime processes may be wholly managed by the cloud provider. In this case, security teams will need to rely on the cloud provider to patch and configure vulnerable components.
Second, infosec professionals need to understand the configuration options available. As noted earlier, SELinux policies -- with enforcing mode enabled -- may prevent this kind of attack from succeeding. This is because the kernel now only allows explicit operations to occur, as opposed to a more permissive stance applied. While this would seem to make logical sense in every case, many Linux container hosts do not apply SELinux enforcing mode. This is often due to performance and troubleshooting headaches that may arise from a more restrictive kernel functional model.
Third, admins must understand the potential risks posed by orchestration and automation tools used for container deployments. Many orchestration tools, such as Kubernetes and Docker Swarm, may modify some of the kernel controls and parameters responsible for security. While these modifications facilitate smoother and more automated deployment and deprovisioning of multiple container workloads simultaneously on a host, they present some security vulnerabilities. Kubernetes, for example, has notoriously disabled Linux kernel secure computing policies, which restrict system calls that can be made on the host. This could make it easier for container escape vulnerabilities to be exploited in environments where these tools are in use.
Organizations can implement several controls to help mitigate these container escape vulnerabilities. If possible, patch and update all runtime components in the organization's container environments, and push cloud service providers to do the same in a timely manner. Also, carefully restrict and control container images. Protect containers with some form of runtime protection tools that integrate into leading IaaS and PaaS cloud environments. Finally, consider configuration and orchestration options carefully, ranging from kernel policies, like SELinux, to orchestration tool behaviors and policies.
