A new serious vulnerability in container technology was publicly reported on Feb. 11, one that could potentially enable an attacker to gain unauthorized access to the host operating system.
Container technology led by the Docker engine has become increasingly popular in recent years as a way to build and deploy applications into isolated segments, on top of a server operating system. At the core of the modern container technology stack is a low-level component known as runc, which spawns and runs containers. The new CVE-2019-5736 vulnerability is a flaw in runc that could enable a malicious container to escape the confines of its isolated process segment.
“The vulnerability allows a malicious container to (with minimal user interaction) overwrite the host runc binary and thus gain root-level code execution on the host,” Aleksa Sarai, senior software engineer at SUSE, wrote in an advisory.
With containers, the running container application is supposed to be isolated from underlying operating system. With the CVE-2019-5736 vulnerability, an attacker could potentially get access to the underlying operating system, putting all the containers that run on the host, as well as the host itself, at risk.
There are other reasons why a malicious container could escape isolation. These include privilege misconfiguration, which was the case with the Play-With-Docker in an issue disclosed by CyberArk on Jan. 14.
CVE-2019-5736 Patches
A patch has been made publicly available in the upstream runc project and multiple vendors and cloud providers are currently pushing the updates where necessary.
Google noted in advisory that Google Kubernetes Engine (GKE) Ubuntu nodes are impacted by the CVE-2019-5736 vulnerability. Other GKE nodes that are not running are Ubuntu are not impacted by the flaw.
Multiple services at Amazon Web Services (AWS) are impacted by CVE-2019-5736, as AWS uses containers and runc extensively thoughout its cloud infrastructure. Among the impacted services are Amazon Linux, Amazon Elastic Container Service (ECS), Elastic Container Service for Kubernetes (EKS), AWS Fargate, IoT Greengrass, AWS Batch, Elastic Beanstalk, Cloud9, Sagemaker, RoboMaker and the Deep Learning AMI.
AWS has provided full details in its advisory to assist users on updating the impacted components to mitigate the risk from the flaw.
Across container vendors, updates are also being issued. Red Hat has advised its customers to update to help minimize risk, though the Linux vendor is also emphasizing that there are also other mitigating controls that users already have in place. Red Hat makes use of SELinux (Security Enhanced Linux) which provides additional layers of access controls for a given process or application.
“This vulnerability is mitigated by the use of SELinux in targeted enforcing mode, which completely prevents this vulnerability from being exploited,” Red Hat notes in its advisory. “The default for SELinux on Red Hat Enterprise Linux 7 is targeted enforcing mode.”
One of the other ways that security experts commonly recommend to help secure containers is with the use of a virtual machine. By running a container engine inside of a VM, there is an additional layer of isolation between an application and a host operating system. Scott McCarty, principal product manager, Containers at Red Hat told eWEEK that using VMs could potentially mitigate the impact of CVE-2019-5736, but only to an extent.
“This CVE would not permit malicious code from breaking out of the OpenShift node in the Virtual Machine,” McCarty said. “But any number of containers could be scheduled on the host at any given time, because that’s how Kubernetes works, if nodes die, it reschedules them.”
As such, McCarty added that even if malicious code couldn’t break out, Kubernetes might send good code in that would then “catch on fire.”
“SELinux is still the best tool to mitigate at the host level,” he said.
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.