The Kubernetes project has patched today a dangerous security flaw that could allow for clever hacks where attackers may run code on the host machine.
The vulnerability doesn't impact the Kubernetes system itself, but kubectl (Kube control), the official command-line utility for working with Kubernetes installations.
Security researchers have discovered a security flaw in the kubectl cp (copy) operation that is used to transfer files from containers to a user's host machine.
Hackers can execute code via "copy" operation
"To copy files from a container, Kubernetes runs tar inside the container to create a tar archive, copies it over the network, and kubectl unpacks it on the user's machine," said Joel Smith, a member of the Kubernetes Product Security Committee.
"If the tar binary in the container is malicious, it could run any code and output unexpected, malicious results. An attacker could use this to write files to any path on the user's machine when kubectl cp is called, limited only by the system permissions of the local user," he said.
Exploiting this flaw isn't simple, as an attacker would need to first place malicious files inside a Kubernetes container, and then wait for a Kubernetes admin to transfer those files to his system.
The malicious files would execute automatically; however, this attack also relies on luck and a little bit of social engineering.
Host machine hack can lead to total compromise
Nevertheless, Wei Lien Dang, Co-Founder and Vice President of Product at StackRox, sees this vulnerability as very dangerous, regardless.
"This vulnerability is concerning because it would allow an attacker to overwrite sensitive file paths or add files that are malicious programs, which could then be leveraged to compromise significant portions of Kubernetes environments," Wei told ZDNet in an email last week.
"This type of exploit shows how a client-side vulnerability could be used to potentially compromise production environments, especially since we have observed that best practices to mitigate against this type of threat vector are not always followed.
"For example, users may be running kubectl on production nodes or without appropriate role-based access control to limit access to the entire cluster or with elevated local system permissions," Wei added.
"In addition, the fix, which is to upgrade to recent versions of kubectl, can be harder to enforce since it is dependent on individual users doing so," the StackRox exec said.
Vulnerability patched twice now
This vulnerability, tracked as CVE-2019-11246, was discovered by Charles Holmes of Atredis Partners, and was found as part of a security audit sponsored by the Cloud Native Computing Foundation.
"This vulnerability stems from incomplete fixes for a previously disclosed vulnerability (CVE-2019-1002101)," Wei said, pointing to a vulnerability first fix in March this year.
"The details for this vulnerability are very similar to CVE-2019-1002101. The original fix for that issue was incomplete and a new exploit method was discovered," Smith said.
Companies and developers who run their own Kubernetes installations are advised to upgrade kubectl and Kubernetes to versions 1.12.9, 1.13.6, or 1.14.2 or later.
Run kubectl version --client and if it does not say client version 1.12.9, 1.13.6, or 1.14.2 or newer, you are running a vulnerable version.
Google Cloud k8s also vulnerable
In a security advisory published today, Google Cloud admins said that "all Google Kubernetes Engine (GKE) gcloud versions are affected by this vulnerability, and we recommend that you upgrade to the latest patch version of gcloud when it becomes available."
Currently, this patch is not out yet.
"An upcoming patch version will include a mitigation for this vulnerability," Google said. Google Cloud customers are advised to keep an eye out for the tool's changelog for the kubectl-related security fixes.
Data leaks: The most common sources
More vulnerability reports: