Google Kubernetes Engine Sandbox mitigates container escape vulnerabilities

Companies running applications that use untrusted code can experience “container escape,” a vulnerability tracked as CVE-2019-5736, that can hijack the shared host operating system and wreak havoc from there.

According to the Information Technology Library, runc used in Docker before 18.09.2 and other products, allows attackers to overwrite the host runc binary within a new container with an attacker-controlled image, or an existing container, to which the attacker previously had write access, that can be attached with docker exec.

In container escape, a flaw in the container runtime or in the host kernel could allow a process running within a container to “escape” the container and affect the node’s kernel, potentially bringing down the node. If the vulnerability is left unpatched, hackers can break out of sandboxes and gain root access on the host servers, compromising the entire infrastructure.

At last month’s Google Cloud Next event, Google announced the Google Kubernetes Engine (GKE) Sandbox beta in hopes of solving this issue.

GKE Sandbox is based on gVisor, the open-source container sandbox runtime that Google released last year. It was created to defend against a host compromise when running arbitrary, untrusted code, while still integrating with container-based infrastructure, according to the company.

“GKE Sandbox’s userland kernel acts as a firewall between applications and the cluster node’s kernel, preventing a compromised application from exploiting other applications through it,” explained Catherine Jones,  the Infrastructure Security Engineer at Shopify, a Canadian e-commerce company that uses GKE Sandbox.

GVisor manages and places restrictions on file and network operations, ensuring that there are two isolation layers between the containerized application and the host OS.

In addition, GKE Sandbox helps teams running multi-tenant clusters, such as SaaS providers, who often execute unknown or untrusted code.

Other companies in the containers realm have their own remedies. For example, Docker containers use Linux kernel namespaces to restrict any user, including root, from directly accessing the machine’s resources.