Kubernetes api server: build config to a strategy that isn't allowed by policy

External reference: https://github.com/openshift/origin/issues/6556 https://github.com/openshift/origin/pull/6576

In all Kubernetes versions prior to v1.10.11, v1.11.5, and v1.12.3, incorrect handling of error responses to proxied upgrade requests in the kube-apiserver allowed specially crafted requests to establish a connection through the Kubernetes API server to backend servers, then send arbitrary requests over the same connection directly to the backend, authenticated with the Kubernetes API server's TLS credentials used to establish the backend connection.

Kubernetes version 1.5.0-1.5.4 is vulnerable to a privilege escalation in the PodSecurityPolicy admission plugin resulting in the ability to make use of any existing PodSecurityPolicy object.

In Kubernetes versions 1.9.0-1.9.9, 1.10.0-1.10.5, and 1.11.0-1.11.1, user input was handled insecurely while setting up volume mounts on Windows nodes, which could lead to command line argument injection.

Prior to 3385, the user-controlled role parameter enters the application in the Kubernetes::RoleVerificationsController. The role parameter flows into the RoleConfigFile initializer and then into the Kubernetes::Util.parsefile method where it is unsafely deserialized using the YAML.loadstream method. This issue may lead to Remote Code Execution (RCE). This vulnerability is fixed in 3385.

It was found that Kubernetes as used by Openshift Enterprise 3 did not correctly validate X.509 client intermediate certificate host name fields. An attacker could use this flaw to bypass authentication requirements by using a specially crafted X.509 certificate.

In Kubernetes v1.12.0-v1.12.4 and v1.13.0, the rest.AnonymousClientConfig() method returns a copy of the provided config, with credentials removed (bearer token, username/password, and client certificate/key data). In the affected versions, rest.AnonymousClientConfig() did not effectively clear service account credentials loaded using rest.InClusterConfig()

A flaw was found in Kubernetes. This issue allows Windows workloads to run as a ContainerAdministrator even when the workloads set the runAsNonRoot option to true.

An authorization flaw was discovered in Kubernetes; the API server did not properly check user permissions when handling certain requests. An authenticated remote attacker could use this flaw to gain additional access to resources such as RAM and disk space.

Kubernetes Dashboard before 1.10.1 allows attackers to bypass authentication and use Dashboard's Service Account for reading secrets within the cluster.

A symlink race in the openShift node process allows a malicious container to trick the node into deleting any file.

Every sync iteration, the atomic writer code walks the volume looking for files that shouldn't be there or files that have changed. When it finds files that shouldn't be there, it adds them to a list. Once it's finished walking the tree, it sorts the list lexicographically then starts at the end (to make sure that files are removed before the directories that contain them) and removes them one by one.

Because (a) the volume isn't mounted read-only by the runtime and (b) there is a time between finding the file and deleting the file, a malicious container can set up conditions to win a race such that the file to be deleted is removed and replaced with a symlink (to a node file to be deleted) between the time that the kubelet finds the file and the time it deletes it.

A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they include Windows nodes.

Any Kubernetes environment with Windows nodes is impacted. Run kubectl get nodes -l kubernetes.io/os=windows to see if any Windows nodes are in use.

A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they include Windows nodes. Any kubernetes environment with Windows nodes is impacted. Run kubectl get nodes -l kubernetes.io/os=windows to see if any Windows nodes are in use.

A denial of service vulnerability was found in the Kubernetes API server. A remote user, with authorization to apply patches, could exploit this via crafted JSON input, causing excessive consumption of resources and subsequent denial of service.

The kubectl cp command allows copying files between containers and the user machine. To copy files from a container, Kubernetes creates a tar inside the container, 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. The untar function can both create and follow symbolic links. The issue is resolved in kubectl v1.11.9, v1.12.7, v1.13.5, and v1.14.0.

A vulnerability has been discovered in kubectl cp that allows a combination of two symlinks to copy a file outside of its destination directory. This could be used to allow an attacker to place a netfarious file using a symlink, outside of the destination tree.

Reference: https://github.com/kubernetes/kubernetes/pull/82143 https://github.com/kubernetes/kubernetes/pull/82143 https://github.com/kubernetes/kubernetes/pull/82384 https://github.com/kubernetes/kubernetes/pull/82502 https://github.com/kubernetes/kubernetes/pull/82503

In Kubernetes versions 1.5.x, 1.6.x, 1.7.x, 1.8.x, and prior to version 1.9.6, the kubectl cp command insecurely handles tar data returned from the container, and can be caused to overwrite arbitrary local files.

Jordan Liggitt of Atomic OpenShift reports:

UPSTREAM: 17886: pod log location must validate container if provided #6113 has security implications, specifically a running pod could make an API call to view the logs of any pod running on the same Node.

External references:

https://github.com/openshift/origin/pull/6113

In Kubernetes v1.8.x-v1.14.x, schema info is cached by kubectl in the location specified by --cache-dir (defaulting to $HOME/.kube/http-cache), written with world-writeable permissions (rw-rw-rw-). If --cache-dir is specified and pointed at a different location accessible to other users/groups, the written files may be modified by other users/groups and disrupt the kubectl invocation.

Kubernetes in OpenShift3 allows remote authenticated users to use the private images of other users should they know the name of said image.

Improper validation of URL redirection in the Kubernetes API server in versions prior to v1.14.0 allows an attacker-controlled Kubelet to redirect API server requests from streaming endpoints to arbitrary hosts. Impacted API servers will follow the redirect as a GET request with client-certificate credentials for authenticating to the Kubelet.

In Kubernetes v1.8.x-v1.14.x, schema info is cached by kubectl in the location specified by --cache-dir (defaulting to $HOME/.kube/http-cache), written with world-writeable permissions (rw-rw-rw-). If --cache-dir is specified and pointed at a different location accessible to other users/groups, the written files may be modified by other users/groups and disrupt the kubectl invocation.

Upstream issue:

https://github.com/kubernetes/kubernetes/issues/76676