===================================================================== CERT-Renater Note d'Information No. 2022/VULN425 _____________________________________________________________________ DATE : 17/11/2022 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Kubernetes kube-apiserver versions prior to 1.25.3, 1.24.7, 1.23.13, 1.22.15. ===================================================================== https://groups.google.com/g/kubernetes-announce/c/oR2PUBiODNA https://groups.google.com/g/kubernetes-announce/c/eR0ghAXy2H8 _____________________________________________________________________ [Security Advisory] CVE-2022-3162: Unauthorized read of Custom Resources Hello Kubernetes Community, A security issue was discovered in Kubernetes where users authorized to list or watch one type of namespaced custom resource cluster-wide can read custom resources of a different type in the same API group without authorization. This issue has been rated Medium (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), and assigned CVE-2022-3162 Am I vulnerable? Clusters are impacted by this vulnerability if all of the following are true: There are 2+ CustomResourceDefinitions sharing the same API group Users have cluster-wide list or watch authorization on one of those custom resources. The same users are not authorized to read another custom resource in the same API group. Affected Versions Kubernetes kube-apiserver <= v1.25.3 Kubernetes kube-apiserver <= v1.24.7 Kubernetes kube-apiserver <= v1.23.13 Kubernetes kube-apiserver <= v1.22.15 How do I mitigate this vulnerability? Upgrading the kube-apiserver to a fixed version mitigates this vulnerability. Prior to upgrading, this vulnerability can be mitigated by avoiding granting cluster-wide list and watch permissions. Fixed Versions Kubernetes kube-apiserver v1.25.4 Kubernetes kube-apiserver v1.24.8 Kubernetes kube-apiserver v1.23.14 Kubernetes kube-apiserver v1.22.16 These releases will be published over the course of today, November 10th. Detection Requests containing `..` in the request path are a likely indicator of exploitation. Request paths may be captured in API audit logs, or in kube-apiserver HTTP logs. If you find evidence that this vulnerability has been exploited, please contact secu...@kubernetes.io Additional Details See the GitHub issue for more details: https://github.com/kubernetes/kubernetes/issues/113756 Acknowledgements This vulnerability was reported by Richard Turnbull of NCC Group as part of the Kubernetes Audit. Thank You, Tim Allclair on behalf of the Kubernetes Security Response Committee _____________________________________________________________________ [Security Advisory] CVE-2022-3294: Node address isn't always verified when proxying Hello Kubernetes Community, A security issue was discovered in Kubernetes where users may have access to secure endpoints in the control plane network. Kubernetes clusters are only affected if an untrusted user can modify Node objects and send proxy requests to them. Kubernetes supports node proxying, which allows clients of kube-apiserver to access endpoints of a Kubelet to establish connections to Pods, retrieve container logs, and more. While Kubernetes already validates the proxying address for Nodes, a bug in kube-apiserver made it possible to bypass this validation. Bypassing this validation could allow authenticated requests destined for Nodes to to the API server's private network. This issue has been rated Medium (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H), and assigned CVE-2022-3294 Am I vulnerable? Clusters are affected by this vulnerability if there are endpoints that the kube-apiserver has connectivity to that users should not be able to access. This includes: kube-apiserver is in a separate network from worker nodes localhost services mTLS services that accept the same client certificate as nodes may be affected. The severity of this issue depends on the privileges & sensitivity of the exploitable endpoints. Clusters that configure the egress selector to use a proxy for cluster traffic may not be affected. Affected Versions Kubernetes kube-apiserver <= v1.25.3 Kubernetes kube-apiserver <= v1.24.7 Kubernetes kube-apiserver <= v1.23.13 Kubernetes kube-apiserver <= v1.22.15 How do I mitigate this vulnerability? Upgrading the kube-apiserver to a fixed version mitigates this vulnerability. Aside from upgrading, configuring an egress proxy for egress to the cluster network can mitigate this vulnerability. Fixed Versions Kubernetes kube-apiserver v1.25.4 Kubernetes kube-apiserver v1.24.8 Kubernetes kube-apiserver v1.23.14 Kubernetes kube-apiserver v1.22.16 These releases will be published over the course of today, November 10th. Fix impact: In some cases, the fix can break clients that depend on the nodes/proxy subresource, specifically if a kubelet advertises a localhost or link-local address to the Kubernetes control plane. Detection Node create & update requests may be included in the Kubernetes audit log, and can be used to identify requests for IP addresses that should not be permitted. Node proxy requests may also be included in audit logs. If you find evidence that this vulnerability has been exploited, please contact secu...@kubernetes.io Additional Details See the GitHub issue for more details: https://github.com/kubernetes/kubernetes/issues/113757 Acknowledgements This vulnerability was reported by Yuval Avrahami of Palo Alto Networks. Thank You, Tim Allclair on behalf of the Kubernetes Security Response Committee ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =========================================================