March 11, 20200 mins read
Over the past few years, Kubernetes has exploded into the tech world, becoming the most popular cloud container orchestration system. Kubernetes remains a powerful, useful open source system for developers, but like any tool needs to be used carefully and you should take steps to secure your clusters. Today we want to talk about two recent vulnerabilities (CVE-2019-11247 and CVE-2019-11249) and how you can address them.
Kubernetes directory traversal vulnerabilities
A directory traversal is a type of attack that allows hackers to access restricted directories and files outside the server’s root directory. By manipulating URLs, it’s possible to force an application to reveal "restricted" files or execute commands for which the user technically shouldn’t have permission.
Unlike other types of attacks, a directory traversal finds loopholes in the otherwise correctly functioning developer security policy. There aren’t necessarily any bugs in the code. Everything is working correctly. Rather, permissions, paths, or file access configurations are either incorrect or insufficient.
Trouble began close to two years ago with a classic directory traversal vulnerability with the kubectl cp operation. In this case, malicious code in containers could write any file to any path on the node (machine) where it was copied from due to the insecure handling of TAR data. It was not difficult to climb the directory to discover the names or files.
Subsequent fixes attempted to sanitize directory paths by stripping path traversals, but the problem wasn’t entirely solved. Following the patch, it was discovered that malicious actors could still manipulate path by creating and following symbolic links from headers in TAR archives.
A third directory traversal issue was identified in early 2019 using kubectl cp operation. Malicious actors could copy files and directories between containers and nodes using malicious TAR binary in a downloaded container. Effectively, a hacker could replace or create files on a user’s machine even if that location was outside of the destination directory of the kubectl cp operation.
In August, Kubernetes released CVE-2019-11249, which involved a fix that finally corrected the directory traversal vulnerability. The kubectl cp operation now performs much more rigorous verifications for the target path of every file during TAR archive decompression. It’s no longer possible to copy decompressed files to paths other than the destination directory of the original kubectl cp operation.
A brief look at CPE-2019-11247
Around the same time that directory traversal vulnerability was fixed, the CVE-2019-11247 vulnerability was discovered. This vulnerability allowed malicious actors to read, modify, or delete cluster-wide custom resources even if their permission roles only allowed them to access resources within their own namespace, or section of the cluster.
The directory traversal vulnerability and CPE-2019-11247 vulnerability are similar in that users could access parts of the container (and therefore nodes) to which they shouldn’t (or don’t) have permission.
However, CPE-2019-11247 was a vulnerability stemming from how the API server interpreted security permissions in relation to where the API endpoint was scoped. The directory traversal vulnerability, on the other hand, was the result of insufficient security permissions. This was fundamentally a problem with role-based access control (RBAC). In other words, if a global (cluster-wide) custom resource was scoped to a namespace and the account calling to the resource had a certain role definition (such as a wildcard), it was possible to bypass the namespace and manipulate global resources.
Remediation Steps for CVE-2019-11247 and CVE-2019-11249
Upgrade Kubernetes to a patched version:All users are strongly advised to upgrade their clusters and kubectl clients to a patched version. Kubernetes 1.13.9, 1.14.5, and 1.15.2 all contain patches that address both vulnerabilities. Users running 1.12 or below will need to refer to official documentation to determine the correct course of action for upgrading. If you are using 1.12 or below, it is time to upgrade–1.12 is in end of life.
If upgrading isn’t available, remove wildcard role definitions from the whole cluster:Some users running on managed platforms may not be able to upgrade immediately. In this case, remove wildcard permissions (indicated by a *) for resources or apiGroups.
Do Not Remove RBAC From a Cluster
Clusters that aren’t running with RBAC enabled aren’t affected by CVE-2019-11249, and in theory, are also not affected by CVE-2019-11247. However, not using RBAC represents an even larger security risk as all accounts will have root access. Do not remove RBAC from a cluster even as a "temporary quick fix."
The effects of this Kubernetes vulnerability will vary between clusters according to the nature of each cluster and what resources are being used within them. Still, vulnerability within Kubernetes is a serious issue as more and more organizations rely on it to orchestrate their cloud containers. The latest patches are believed to fix CVE-2019-11247 and CVE-2019-11249.
However, security is an ongoing endeavor. If anything, these patches reflect the reality that hackers will always find clever ways to exploit loopholes and bugs in codes. Stay safe by staying upgraded and up to date on Kubernetes security.