Container security vulnerability prompts call to patch runC
The discovery of a container utility flaw means IT pros must patch most container runtimes, as well as practice defense in depth and beware of strangers with sketchy container images.
A newly discovered container security vulnerability turns up the heat for enterprises, as technologies such as Docker and Kubernetes move into production.
Security researchers in the Linux community revealed the vulnerability, which could be exploited by an attacker to gain root-level code execution on the container host and potentially control the rest of a container infrastructure for malicious purposes.
This type of attack has been theoretically possible, but Red Hat officials, who publicized the flaw this week and advised users to patch the low-level runC utility, said this is the first time such an exploit has actually been revealed "out in the wild" in the Linux community. In seven days, researchers will also release exploit code that will allow vendors and end users to do penetration testing against patches for Linux containers on SUSE and Red Hat Enterprise Linux operating systems. However, attackers will also have access to the means to exploit the vulnerability.
"You will probably see 'script kiddies' inserting this into anonymous container images all over Docker Hub. And if you download an unknown container image that happens to contain this exploit code, you could be in [trouble]," said Scott McCarty, principal product manager for containers at Red Hat.
Container security best practices get real
The runC utility is core to most container runtimes, so it will take some time and planning to deploy patches for large environments. Stateless web apps can easily apply rolling upgrades to hosts without interruption to applications. Stateful workloads -- still a relative rarity in production on containers -- may experience some interruptions while IT pros apply patches.
In the meantime, users can protect themselves with some well-documented, common-sense best practices in the container security community -- the first of which is not to download and run container images from unverified internet sources.
"[An attack] would require a malicious user to put some nasty stuff in the container image, and then for a user to download that malicious code by mistake," McCarty said. "If you're already doing some container security stuff, such as pulling container images from a trusted source ... you're still probably pretty safe."
Gary Chen
This might seem like a no-brainer, but developers without IT security expertise or under time pressure might still unwittingly download such code, said Gary Chen, analyst at IDC.
"In the worst case, you might also have a malicious insider," Chen said.
Should someone download such an image, many container image scanning utilities can detect it -- from Docker Bench for Security and Notary to Cilium -- though they may require some time to account for this specific vulnerability.
Red Hat also recommended users apply SELinux policies within the host operating system to block unauthorized behavior by compromised containers, which can mitigate this and other container security vulnerabilities, although that isn't necessarily a long-term solution.
"It's like a spare tire: It's good for a few weeks or months while users get systems patched, but I wouldn't want to rely on it for a year," McCarty said.
Analysts urge serious look at container security defense in depth
Assume that container isolation may be brought down. How will you contain that?
Gary Chenanalyst, IDC
This is not the worst-case container security scenario, as this vulnerability was still found by a researcher, rather than after being exploited by an attacker in a real-world environment. Nevertheless, it should prompt enterprise IT shops to analyze their approach to container security defense in depth at the network layer, as well as within hosts, applications and container images.
Here, container runtime security tools such as Aqua, Twistlock and NeuVector offer products that can block anomalous application behavior and network traffic, which would limit the actions that a compromised container with host root access could take in the wider infrastructure. Other open source projects that use stripped-down VMs to isolate containers from hosts, such as gVisor, Kata Containers and Amazon Firecracker, are also meant to address such potential exploits.
Figo.io, a fintech startup in Hamburg, Germany, assumes the presence of vulnerabilities similar to CVE-2019-5736 at all levels of the complete software stack and aims for defense in depth, said Lutz Behnke, platform security engineer.
"In [addition] to rigorously applying minimal permissions for each task, we use NeuVector policy rules to restrict the processes that are executed on each container and the users that initiate them," he said. "These restrictions can trigger alarms or even outright block execution, depending on the criticality of the targeted container."
Ultimately, this runC vulnerability disclosure will force enterprises to think about different layers of container security that they haven't before, IDC's Chen added.
"Assume that container isolation may be brought down. How will you contain that?" he said.
Gary Chen
