Kubernetes Security Hole: Is It a Bug or a Boomerang?
A Kubernetes security issue seems to be paraphrasing the old Energizer Bunny commercial: it keeps returning, and returning, and returning.
June 26, 2019
![ships wheel that looks like Kubernetes logo ships wheel that looks like Kubernetes logo](https://eu-images.contentstack.com/v3/assets/blt07f68461ccd75245/bltec33475f91761bb4/66194832b642ab718b9deacc/ships-wheel_1.jpg?width=1280&auto=webp&quality=95&format=jpg&disable=upscale)
If it were a song, the latest security vulnerability affecting Kubernetes might be called something like "Long Train A Coming," and not just because it has Kubernetes security experts singing the blues, but because the bug is tied to another bug that wasn't quite completely patched, which was also tied to yet another bug that ... you guessed it, wasn't completely patched.
The vulnerability, dubbed CVE-2019-11246, was discovered by Charles Holmes with the security firm Atredis Partners as part his work with the Cloud Native Computing Foundation-sponsored Kubernetes Third-party Security Audit. It affects the kubectl cp command, and can be exploited to cause a malicious container to replace or create files on a user’s workstation.
"The vulnerability is a client-side defect and requires user interaction to be exploited," Red Hatter Joel Smith said in a post for the Kubernetes Product Security Committee. He listed the exploit as "high severity" and recommended upgrading kubectl to Kubernetes 1.12.9, 1.13.6, and 1.14.2 or later to fix the issue.
"The kubectl cp command allows copying files between containers and the user machine," he said. "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.
"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."
Smith said that Kubernetes users can check for vulnerability by running the command "kubectl version --client". A return of client versions 1.12.9, 1.13.6, or 1.14.2 or newer means you're OK -- otherwise, you're vulnerable.
The bug is similar and related to CVE-2019-1002101, which was discovered in March by researcher Ariel Zelivansky with the container security company Twistlock. At the time Zelivansky noted that bug was an outgrowth of yet another vulnerability, CVE-2018-1002100, that had been discovered and patched a year previously. Both patches, it appears, were incomplete.
Those with vulnerable systems can find instructions for updating kubectl on a Kubernetes webpage, although Smith warns that "not all instructions will provide up-to-date kubectl versions at the time of this announcement. So, always confirm with kubectl version."
After you're through, be sure to cross your fingers and try to have faith in the old adage that "the third time's the charm."
About the Author
You May Also Like