The discovery of a major security flaw in the common open-source runtime engine for Docker, Kubernetes and other container management systems, points to an underlying risk associated with containerized applications.
Researchers Adam Iwaniuk and Borys Popławsk discovered the vulnerability, CVE-2019-5736, in RunC, the common runtime engine developed by Docker and now a common Open Container Initiative (OCI) specification used across most modern container images, such as Alpine, Debian, Mesos and Red Hat, among others. Aleksa Sarai, one of the community maintainers of RunC, this week verified the vulnerability.
“That fear of container isolation failing to hold up turned out to be true,” noted Asif Awan, CTO for containers at vulnerability management provider Qualys, in a post warning of the RunC hole. Unpatched, experts noted that the RunC vulnerability poses even greater risk than a flaw that impacted Kubernetes 1.10 and higher, discovered two months ago.
The discovery drew widespread concern because RunC is nearly ubiquitous in modern containerized applications. “As far as container runtimes go, RunC is used by just about every container engine out there – it’s a fundamental component of even the most basic Linux container implementations as a low-level runtime,” noted Scott McCarty, Red Hat’s principal product manager for containers, in a post warning of the vulnerability.
McCarty noted that a broad range of container infrastructure and Kubernetes orchestration offerings, including the Red Hat OpenShift Container Platform, use RunC. While he and the broad ecosystem of security, application and cloud providers all urged customers to patch their systems, Red Hat platforms ship with SELinux in “enforcing mode,” which should protect against exploitation of the RunC flaw, McCarty noted.
An attacker exploiting the RunC flaw could potentially inflict significant damage, according to experts. Banjot Chanana, Docker’s VP of product, warned in a blog post that a malicious container image could gain administrative privileges to a host. In a worst-case scenario, an attacker could gain access to an entire cluster, Shiri Ivtsan, a product manager at WhiteSource, a provider of security, licensing and reporting tools for open-source environments, told ITOps Times.
“It has very serious implications if a hacker goes into the cluster,” Ivtsan said. “They can do basically whatever they want. They can delete users, they can inject any code that they want into applications and they can even see data.”
While the December Kubernetes vulnerability also enabled privilege escalation, Ivtsan explained the RunC flaw is potentially more dangerous. “This is bigger than just Kubernetes because it’s tied to the Docker container image,” she said.
Gavin Millard, VP of Intelligence at cybersecurity risk assessment platform provider Tenable, shared a similar concern. “You have to take these vulnerabilities very seriously, especially as a lot of the cloud providers leverage Kubernetes and Docker containerization,” he said.
Moreover, the discovery of the RunC flaw validates the fear that just because containers are isolated, that doesn’t make them more secure, according to Qualys’ Awan. “The announced vulnerability allows an attacker to break out of the container isolation through a well-crafted attack and compromise the entire host,” Awan noted. “The vulnerability is particularly nasty because it is not covered by the default AppArmor or SELinux kernel-enforced sandboxing policies.”
For its part, Docker’s engineering team worked with the RunC maintainers to create and issue a patch, according to Chanana. “Docker recommends immediately applying the update to avoid any potential security threats,” he noted. Chanana advised that systems with Docker Engine-Community should be updated to 18.09.2 or 18.06.2, and those with Docker Engine-Enterprise should be patched with 18.09.2, 18.03.1-ee-6, or 17.06.2-ee-19.
