Vulnerabilities Found in Kubernetes Container System

Kubernetes is an open source container orchestration system for automating application deployment, scaling and management. Maintained by the Cloud Native Computing Foundation, it originated with Google.

It has been announced that there are security vulnerabilities that have been discovered in the system. CVE-2019-1002101 is determined to be a high severity issue, and CVE-2019-9946 is a medium severity issue.

The first vulnerability is centered around the "kubectl cp" command. It could replace or delete files on a user machine. Indeed, an attacker could write files to any path on the user's machine. It is only limited by the system permissions that a local user has been granted.

The command is used to copy files and directories between containers running in the Kubernetes pods, and the user's machine. It uses the tar binary inside a container for the actual copying. First, it creates a tarball from it, copies that over to the target machine and un-tars it to complete the move.

But someone can place a malicious tarball in a container, and that will be copied over without question. It seems that since the previous fix for CVE-2018-1002100, the un-tar function calls the "cp.go:clean" to strip path traversals contained in the tarball. Ariel Zelivansky of Twistlock realized that function can both create and follow symbolic links, which means there are no limits on the paths that can be created for the files embedded in the tarball. Bingo. Files can be put anywhere by an attacker.

To determine if they are affected, a user must run "kubectl version —client". If it does not say version 1.11.9, 1.12.7, 1.13.5 and 1.14.0 or newer then the version is vulnerable. Patch/upgrade is the way to obtain these newer and corrected versions.

The second vulnerability (CVE-2019-9946) involves interactions between the CNI (Container Networking Interface) portmap plugin versions prior to 0.7.5 and Kubernetes. The CNI portmap plugin is embedded into Kubernetes so a fixed Kubernetes is required to mitigate.

The issue was identified in a configuration of kube-proxy in IPVS mode along with a pod using a HostPort. However, other network configurations may use the CNI portmap plugin as well so the problem may extend beyond the identified one.

Etienne Champetier of Anevia first identified the problem, which has to do with the way in which the iptables are set up. Simply, the HostPort/portmap rule could match incoming traffic even if there were better fitting, more specific service definition rules like NodePorts later in the chain. That means bad matches could be made when it is running.

Switching the portmap plugin to append its rules, rather than prepend, means that traffic will be processed by KUBE-SERVICES rules first, which is how things are intended to go.

Ali Golshan, CTO and co-founder of StackRox, told Security Now in a message that, "While there is no evidence of either vulnerability being exploited in the wild, both CVEs could be leveraged by malicious actors to execute a number of common attacks on Kubernetes environments, i.e. ransomware and crypto mining attacks, data theft, and/or service disruption. Should an attacker exploit these vulnerabilities in an enterprise environment, the business impact could be massive, not limited to financial catastrophe, reputational damage, or legal consequences."

As far as the second vulnerability goes, he has a more sanguine view. "The good news is that most users will not be impacted with CVE-2019-9946," he said, "since support for network plugins in Kubernetes is still in alpha. However, if you are using the portmap CNI plugin to run HostPorts in your Kubernetes configuration and are unable to upgrade your cluster, you should limit the use of HostPorts in the interim, or use a plugin other than portmap for port-mapping."

— Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been, among other things, a consulting editor for BYTE magazine and senior editor for the launch of WebWeek.