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.
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.
Node address isn't always verified when proxying
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.
A flaw was found in kubernetes. Clusters running on VSphere, using VSphere as a cloud provider a with logging level set to 4 or above, VSphere cloud credentials will be leaked in the cloud controller manager's log.
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
The debugging endpoint /debug/pprof is exposed over the unauthenticated Kubelet healthz port. The go pprof endpoint is exposed over the Kubelet's healthz port. This debugging endpoint can potentially leak sensitive information such as internal Kubelet memory addresses and configuration, or for limited denial of service. Versions prior to 1.15.0, 1.14.4, 1.13.8, and 1.12.10 are affected. The issue is of medium severity, but not exposed by the default configuration.
A third issue was discovered with the Kubernetes kubectl cp command that could enable a directory traversal such that a malicious container could replace or create files on a user’s workstation. The vulnerability is a client-side defect and requires user interaction to be exploited.
This vulnerability allows a malicious container to cause a file to be created or replaced on the client computer when the client uses the kubectl cp operation. The vulnerability is a client-side defect and requires user interaction to be exploited.
Upstream Issue:
https://github.com/kubernetes/kubernetes/issues/80984
External References:
https://groups.google.com/forum/#!topic/kubernetes-security-discuss/Vf31dXp0EJc
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
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.
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()
Cloud Native Computing Foundation (CNCF) CNI (Container Networking Interface) 0.7.4 has a network firewall misconfiguration which affects Kubernetes. The CNI 'portmap' plugin, used to setup HostPorts for CNI, inserts rules at the front of the iptables nat chains; which take precedence over the KUBE- SERVICES chain. Because of this, the HostPort/portmap rule could match incoming traffic even if there were better fitting, more specific service definition rules like NodePorts later in the chain. The issue is fixed in CNI 0.7.5 and Kubernetes 1.11.9, 1.12.7, 1.13.5, and 1.14.0.
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 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.
Kubernetes Dashboard before 1.10.1 allows attackers to bypass authentication and use Dashboard's Service Account for reading secrets within the cluster.
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.
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.
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 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.
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.
In Kubernetes versions 1.3.x, 1.4.x, 1.5.x, 1.6.x and prior to versions 1.7.14, 1.8.9 and 1.9.4 containers using subpath volume mounts with any volume type (including non-privileged pods, subject to file permissions) can access files/directories outside of the volume, including the host's filesystem.
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.
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.
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
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 in OpenShift3 allows remote authenticated users to use the private images of other users should they know the name of said image.
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