Published on 00/00/0000
Last updated on 00/00/0000
Published on 00/00/0000
Last updated on 00/00/0000
Share
INSIGHTS
3 min read
Published on 04/11/2020
Last updated on 06/18/2024
Kubernetes “kubectl cp” Command to Jeopardize Cloud-Based Host Instances
Share
A security issue was recently discovered with the Kubernetes kubectl cp command that could potentially enable a directory traversal to replace or delete files on a user’s workstation or cloud instance. This is a high severity issue, and it is recommended to upgrade kubectl to Kubernetes 1.11.9, 1.12.7, 1.13.5, or 1.14.0. See CVE-2019-1002101 and the fix.
The latest security issue was initially found earlier this month by Ariel Zelivansky, a security researcher at Twistlock.
Vulnerability Details
The kubectl cp command is used to copy files between containers and the user machine or cloud instance. To copy files from a container, Kubernetes first creates a tar file inside the container, copies it over the network, and then kubectl unpacks it on the user’s machine or cloud instance. 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. Since an earlier vulnerability, CVE-2018-1002100 was fixed, the untar function calls cp.go:clean to strip path traversals. However, this function can both create and follow symbolic links. Consider the following scenario in which the user uses kubectl cp to copy a malicious tar file hosted within a container. This file contains both a malicious piece of code and a symbolic link to that of a target directory e.g. /proc/john/cron → /evildir/evil. In this situation, once the user runs the cron job, it will run the malicious code of the attacker, and even with non-root permissions, this would be extremely dangerous.Impact
This vulnerability can be harmful in one of two scenarios:- If a user downloads a malicious container image with a bad tar, or even uses a bad open source.
- An attacker gets access to a running container using another exploit, or through legitimate access e.g. a misconfiguration of an SG, or access list network credentials.
The Cisco Cloud Native Security solution
By following two simple steps, opening a Cisco Cloud Native Security account, and installing Cisco on your cluster, using a single yaml file, the Cisco Cloud Native Security platform will provide runtime cryptographic identity validation for any file or workload on the host. A workload executed without a properly validated identity will be detected immediately and, optionally, killed. Moreover, any attempted communication from this workload to a valid service on the host will be detected, intercepted, and dropped. In the example below, we detected an unidentified workload copied from Customer/Cluster-A while trying to masquerade itself as an OS process ‘agetty’. It also identified an unidentified process attempting to communicate to a Postgres database and blocked it.
Conclusion
Although this vulnerability could potentially be solved by hardening the container environment, e.g. blocking remote execution of host remote exec (&exec.DefaultRemoteExecutor), or removing kubectl cp or tar from the container, this would be crippling for the DevOps operation. The correct approach is to cryptographically protect the runtime environment.
This vulnerability only affects the user client for Kubernetes, kubectl (and the OpenShift equivalent, oc). All kubectl versions from v1.9.0-alpha.2 to 1.14.0 are vulnerable. Versions 1.11.9, 1.12.7, 1.13.5 have the fix.
Subscribe to
the Shift!
Get emerging insights on innovative technology straight to your inbox.
