A flaw was found in HyperShift's hosted control plane konnectivity-server configuration. The proxy-server is started without the --cluster-ca-cert flag, which means the agent-facing TLS listener is set to tls.NoClientCert and does not request or verify client certificates at all. An attacker with network access to the externally-exposed konnectivity cluster endpoint can connect with an arbitrary or self-signed certificate (or no certificate) and be added to the agent routing pool. Once in the routing pool, the attacker can intercept, modify, or drop control-plane-to-node traffic that the server routes through their connection, including kubectl exec/logs streams, kubelet API calls with pod specs containing secrets, service account tokens, and ConfigMap/Secret data. The fix adds --cluster-ca-cert referencing the existing per-cluster konnectivity CA bundle that is already mounted in the container.

Impact A malicious container can affect the host by taking advantage of code cri-o added to show the container mounts on the host.

A workload built from this Dockerfile: FROM docker.io/library/busybox as source RUN mkdir /extra && cd /extra && ln -s ../../../../../../../../root etc

FROM scratch

COPY --from=source /bin /bin COPY --from=source /lib /lib COPY --from=source /extra .

and this container config:

{ "metadata": { "name": "busybox" }, "image":{ "image": "localhost/test" }, "command": [ "/bin/true" ], "linux": { } }

and this sandbox config { "metadata": { "name": "test-sandbox", "namespace": "default", "attempt": 1, "uid": "edishd83djaideaduwk28bcsb" }, "linux": { "securitycontext": { "namespaceoptions": { "network": 2 } } } }

will create a file on host /host/mtab

Patches 1.30.1, 1.29.5, 1.28.7

Workarounds Unfortunately not

References Are there any links users can visit to find out more?

A security vulnerability was discovered in Kubernetes that could allow a user with create pod permission to exploit gitRepo volumes to access local git repositories belonging to other pods on the same node. This CVE only affects Kubernetes clusters that utilize the in-tree gitRepo volume to clone git repositories from other pods within the same node. Since the in-tree gitRepo volume feature has been deprecated and will not receive security updates upstream, any cluster still using this feature remains vulnerable.

A vulnerability exists in the NodeRestriction admission controller in Kubernetes clusters where node users can delete their corresponding node object by patching themselves with an OwnerReference to a cluster-scoped resource. If the OwnerReference resource does not exist or is subsequently deleted, the given node object will be deleted via garbage collection.

A flaw was found in Kubernetes that allows attackers on adjacent networks to reach services exposed on localhost ports, previously thought to be unreachable. This flaw allows an attacker to gain privileges or access confidential information for any services listening on localhost ports that are not protected by authentication.

A flaw was found in Kubernetes, where the amount of disk space the /etc/hosts file can use is unconstrained . This flaw can allow attacker-controlled pods to cause a denial of service if they have permission to write to the node's /etc/hosts file.

A server side request forgery (SSRF) flaw was found in Kubernetes. The kube-controller-manager allows authorized users with the ability to create StorageClasses or certain Volume types to leak up to 500 bytes of arbitrary information from the master's host network. This can include secrets from the kube-apiserver through the unauthenticated localhost port (if enabled).

The Kubelet component in versions 1.15.0-1.15.9, 1.16.0-1.16.6, and 1.17.0-1.17.2 has been found to be vulnerable to a denial of service attack via the kubelet API, including the unauthenticated HTTP read-only API typically served on port 10255, and the authenticated HTTPS API typically served on port 10250.

A flaw was found in the Kubernetes API server, where it allows an attacker to escalate their privileges from a compromised node. This flaw allows an attacker who can intercept requests on a compromised node, to redirect those requests, along with their credentials, to perform actions on other endpoints that trust those credentials (including other clusters), allowing for escalation of privileges. The highest threat from this vulnerability is to confidentiality, integrity, and system availability.

A flaw was found in kubernetes. In Kubernetes, if the logging level is to at least 4, processing a malformed docker config file will result in the contents of the docker config file being leaked, which can include pull secrets or other registry credentials. This can occur with client tools like kubectl, or other components that use registry credentials in a docker config file.

A flaw was found in kubernetes. In Kubernetes, if the logging level is to at least 9, authorization and bearer tokens will be written to log files. This can occur both in API server logs and client tool output like kubectl. Previously, CVE-2019-11250 was assigned for the same issue for logging levels of at least 4.

A denial of service vulnerability was found in the kube-apiserver, allowing authorized users sending malicious YAML payloads to cause kube-apiserver to consume excessive CPU cycles while parsing YAML.

Upstream Issue:

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

A security issue was discovered in kube-apiserver that could allow node updates to bypass a Validating Admission Webhook. Clusters are only affected by this vulnerability if they run a Validating Admission Webhook for Nodes that denies admission based at least partially on the old state of the Node object. Validating Admission Webhook does not observe some previous fields.

kubectl (k8s.io/kubernetes/pkg/kubectl) does not neutralize escape, meta or control sequences contained in the raw data it outputs to a terminal. This includes but is not limited to the unstructured string fields in objects such as Events.

A flaw was found in kubernetes. If a potential attacker can already create or edit services and pods, then they may be able to intercept traffic from other pods (or nodes) in the cluster.

A denial of service vulnerability was found in the Kubernetes API server. This flaw allows a remote attacker to send repeated, crafted HTTP requests to exhaust available memory and cause a crash.

A security issue was discovered in Kubernetes where a user may be able to redirect pod traffic to private networks on a Node. Kubernetes already prevents creation of Endpoint IPs in the localhost or link-local range, but the same validation was not performed on EndpointSlice IPs.

A security issue was discovered with Kubernetes that could enable users to send network traffic to locations they would otherwise not have access to via a confused deputy attack.

A security issue was discovered in Kubernetes where actors that control the responses of MutatingWebhookConfiguration or ValidatingWebhookConfiguration requests are able to redirect kube-apiserver requests to private networks of the apiserver. If that user can view kube-apiserver logs when the log level is set to 10, they can view the redirected responses and headers in the logs.

As mitigations to a report from 2019 and CVE-2020-8555, Kubernetes attempts to prevent proxied connections from accessing link-local or localhost networks when making user-driven connections to Services, Pods, Nodes, or StorageClass service providers. As part of this mitigation Kubernetes does a DNS name resolution check and validates that response IPs are not in the link-local (169.254.0.0/16) or localhost (127.0.0.0/8) range. Kubernetes then performs a second DNS resolution without validation for the actual connection. If a non-standard DNS server returns different non-cached responses, a user may be able to bypass the proxy IP restriction and access private networks on the control plane.

The Kubernetes kube-controller-manager in versions v1.0-v1.17 is vulnerable to a credential leakage via error messages in mount failure logs and events for AzureFile and CephFS volumes.

A security issue was discovered in Kubernetes where a user may be able to create a container with subpath volume mounts to access files & directories outside of the volume, including on the host filesystem.

A security issue was discovered in Kubernetes where users may be able to launch containers using images that are restricted by ImagePolicyWebhook when using ephemeral containers. Kubernetes clusters are only affected if the ImagePolicyWebhook admission plugin is used together with ephemeral containers.

This issue affects kube-apiserver. Clusters are impacted by this vulnerability if: 1. The ImagePolicyWebhook admission plugin is used to restrict the use of certain images and 2. Pods using ephemeral containers.

A security issue was discovered in Kubernetes where users may be able to launch containers that bypass the mountable secrets policy enforced by the ServiceAccount admission plugin when using ephemeral containers. The policy ensures pods running with a service account may only reference secrets specified in the service account’s secrets field. Kubernetes clusters are only affected if the ServiceAccount admission plugin and the kubernetes.io/enforce-mountable-secrets annotation are used together with ephemeral containers.

This issue affects kube-apiserver. Clusters are impacted by this vulnerability if:

1. The ServiceAccount admission plugin is used. Most clusters should have this on by default as recommended in https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#serviceaccount 2. The kubernetes.io/enforce-mountable-secrets annotation is used by a service account. This annotation is not added by default. 3. Pods using ephemeral containers.

A security issue was discovered in Kubelet that allows pods to bypass the seccomp profile enforcement. Pods that use localhost type for seccomp profile but specify an empty profile field, are affected by this issue. In this scenario, this vulnerability allows the pod to run in unconfined (seccomp disabled) mode. This bug affects Kubelet.

Kube-proxy on Windows can unintentionally forward traffic to local processes listening on the same port (“spec.ports[].port”) as a LoadBalancer Service when the LoadBalancer controller does not set the “status.loadBalancer.ingress[].ip” field. Clusters where the LoadBalancer controller sets the “status.loadBalancer.ingress[].ip” field are unaffected.

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.

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.

A security issue was discovered in Kubernetes where a user that can create pods and persistent volumes on Windows nodes may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they are using an in-tree storage plugin for Windows nodes.

A security issue was discovered in Kubelet that allows pods to bypass the seccomp profile enforcement. Pods that use localhost type for seccomp profile but specify an empty profile field, are affected by this issue. In this scenario, this vulnerability allows the pod to run in unconfined (seccomp disabled) mode. This bug affects Kubelet.

References: https://groups.google.com/g/kubernetes-security-announce/c/QHmx0HOQa10 https://github.com/kubernetes/kubernetes/issues/118690