GHSA-38jw-g2qx-4286 KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer

• Go kubevirt.io/kubevirt: < 1.5.3 → fixed in 1.5.3 • Go kubevirt.io/kubevirt: >= 1.6.0-alpha.0, < 1.6.1 → fixed in 1.6.1 • Go kubevirt.io/kubevirt: >= 1.7.0-alpha.0, < 1.7.0-rc.0 → fixed in 1.7.0-rc.0

Summary _Short summary of the problem. Make the impact and severity as clear as possible. A flawed implementation of the Kubernetes aggregation layer's authentication flow could enable bypassing RBAC controls. Details _Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._ It was discovered that the `virt-api` component fails to correctly authenticate the client when receiving API requests over mTLS. In particular, it fails to validate the CN (Common Name) field in the received client TLS certificates against the set of allowed values defined in the `extension-apiserver-authentication` configmap. The Kubernetes API server proxies received client requests through a component called aggregator (part of K8S's API server), and authenticates to the `virt-api` server using a certificate signed by the CA specified via the `--requestheader-client-ca-file` CLI flag. This CA bundle is primarily used in the context of aggregated API servers, where the Kubernetes API server acts as a trusted front-end proxy forwarding requests. While this is the most common use case, the same CA bundle can also support less common scenarios, such as issuing certificates to authenticating front-end proxies. These proxies can be deployed by organizations to extend Kubernetes' native authentication mechanisms or to integrate with existing identity systems (e.g., LDAP, OAuth2, SSO platforms). In such cases, the Kubernetes API server can trust these external proxies as legitimate authenticators, provided their client certificates are signed by the same CA as the one defined via `--requestheader-client-ca-file`. Nevertheless, these external authentication proxies are not supposed to directly communicate with aggregated API servers. Thus, by failing to validate the CN field in the client TLS certificate, the `virt-api` component may allow an attacker to bypass existing RBAC controls by directly communicating with the aggregated API server, impersonating the Kubernetes API server and its aggregator component. However, two key prerequisites must be met for successful exploitation: • The attacker must possess a valid front-end proxy certificate signed by the trusted CA (`requestheader-client-ca-file`). For example, they can steal the certificate material by compromising a front-end proxy or they could obtain a bundle by exploiting a poorly configured and managed PKI system. • The attacker must have network access to the `virt-api` service, such as via a compromised or controlled pod within the cluster. These conditions significantly reduce the likelihood of exploitation. In addition, the `virt-api` component acts as a sub-resource server, meaning it only handles requests for specific resources and sub-resources . The handled by it requests are mostly related to the lifecycle of already existing resources. Nonetheless, if met, the vulnerability could be exploited by a *Pod-Level Attacker* to escalate privileges, and manipulate existing virtual machine workloads potentially leading to violation of their CIA (Confidentiality, Integrity and Availability). PoC _Complete instructions, including specific configuration details, to reproduce the vulnerability._ Bypassing authentication In this section, it is demonstrated how an attacker could use a certificate with a different CN field to bypass the authentication of the aggregation layer and perform arbitrary API sub-resource requests to the `virt-api` server. The `kube-apiserver` has been launched with the following CLI flags: ```bash admin@minikube:~$ kubectl -n kube-system describe pod kube-apiserver-minikube | grep Command -A 28 Command: kube-apiserver --advertise-address=192.168.49.2 --allow-privileged=true --authorization-mode=Node,RBAC --client-ca-file=/var/lib/minikube/certs/ca.crt --enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota --enable-bootstrap-token-auth=true --etcd-cafile=/var/lib/minikube/certs/etcd/ca.crt --etcd-certfile=/var/lib/minikube/certs/apiserver-etcd-client.crt --etcd-keyfile=/var/lib/minikube/certs/apiserver-etcd-client.key --etcd-servers=https://127.0.0.1:2379 --kubelet-client-certificate=/var/lib/minikube/certs/apiserver-kubelet-client.crt --kubelet-client-key=/var/lib/minikube/certs/apiserver-kubelet-client.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --proxy-client-cert-file=/var/lib/minikube/certs/front-proxy-client.crt --proxy-client-key-file=/var/lib/minikube/certs/front-proxy-client.key --requestheader-allowed-names=front-proxy-client --requestheader-client-ca-file=/var/lib/minikube/certs/front-proxy-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=8443 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/minikube/certs/sa.pub --service-account-signing-key-file=/var/lib/minikube/certs/sa.key --service-cluster-ip-range=10.96.0.0/12 --tls-cert-file=/var/lib/minikube/certs/apiserver.crt --tls-private-key-file=/var/lib/minikube/certs/apiserver.key ``` By default, Minikube generates a self-signed CA certificate (`var/lib/minikube/certs/front-proxy-ca.crt`) and use it to sign the certificate used by the aggregator (`/var/lib/minikube/certs/front-proxy-client.crt`): ```bash inspect the self-signed front-proxy-ca certificate admin@minikube:~$ openssl x509 -text -in /var/lib/minikube/certs/front-proxy-ca.crt | grep -e "Issuer:" -e "Subject:" Issuer: CN = front-proxy-ca Subject: CN = front-proxy-ca inspect the front-proxy-client certificate signed with the above cert $ openssl x509 -text -in /var/lib/minikube/certs/front-proxy-client.crt | grep -e "Issuer:" -e "Subject:" Issuer: CN = front-proxy-ca Subject: CN = front-proxy-client ``` One can also inspect the contents of the `extension-apiserver-authentication` ConfigMap which is used as a trust anchor by all extension API servers: ```bash admin@minikube:~$ kubectl -n kube-system describe configmap extension-apiserver-authentication Name: extension-apiserver-authentication Namespace: kube-system Labels: Annotations: Data ==== requestheader-client-ca-file: ---- -----BEGIN CERTIFICATE----- MIIDETCCAfmgAwIBAgIIN59KhbrmeJkwDQYJKoZIhvcNAQELBQAwGTEXMBUGA1UE AxMOZnJvbnQtcHJveHktY2EwHhcNMjUwNTE4MTQzMTI3WhcNMzUwNTE2MTQzNjI3 WjAZMRcwFQYDVQQDEw5mcm9udC1wcm94eS1jYTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBALOFlqbM1h3uhTdU9XBZQ6AX8S7M0nT5SgSOSItJrVwjNUv/ t4FAQxnGPW7fhp9A9CeQ92DGLXkm88fgHCgnPJuodKgX8fS7NHfswvXKkgo6C4UO 2AmW0NAkuKMyTmf1tWugot7hj3sGFfIzVSLL73wm1Ci8unTaGKZG01ZZalL1kzz9 ObpmEn7DQvSJd7m5gALP4KPJdkFjoagMI4UlIownARl0h2DX5WAKy0ynGfEBvw+P hEbuVPb+egeUVTn9/4JIqdUw21tUQrmbQqPib8BByueiOYqEerGxZDpLAxh230VG Q6omoyUHjE6SIMBoUnAqAdLbTElVbLWJawlLZzECAwEAAaNdMFswDgYDVR0PAQH/ BAQDAgKkMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFPjiIeJVR7zQBCkpmkEa I+70PxA8MBkGA1UdEQQSMBCCDmZyb250LXByb3h5LWNhMA0GCSqGSIb3DQEBCwUA A4IBAQBiNTe9Sdv9RnKqTyt+Xj0NJrScVOiWPb9noO5XSyBtOy8F8b+ZWAtzc+eI G/g6hpiT7lq3hVtmDNiE6nsP3tywXf0mgg7blRC0l3DxGtSzJZlbahAI4/U5yen7 orKiWiD/ObK2rGbt1toVRyvJzPi3hYjh4mA6GMyFbOC6snopNyM9oj+b/EuTCavf l9WTNn2ZZQ1nYfJsLjOY5k/VtpZw1D/QwYt0u/A83RxEeBvK2aZPsq/nA0jqeHhe VHauDQslkjMw0yrFc1b+Ju4Ly+BwH+Mi7ALUINc8EVncWZyM2L7B4N9XwPSp6YPX fZnj69fu0JWfrq88M+LnKOyfkqi4 -----END CERTIFICATE----- requestheader-extra-headers-prefix: ---- ["X-Remote-Extra-"] requestheader-group-headers: ---- ["X-Remote-Group"] reques…