Kubernetes Access Vulnerability Found in Windows Nodes
If, by chance, you are running some Windows nodes somewhere in your Kubernetes clusters and you still utilize the pre-CSI internal plug-ins (K8s v1.27 or earlier), then your system is in grave danger of a privilege escalation attack.
Craig Ingram, a Kubernetes security engineer reported the bug, on behalf of the Kubernetes Security Response Committee, on Tuesday.
The vuln (CVE-2023-5528) has been assessed with high severity, a 7.2 ranking on the Common Vulnerability Scoring System (CVSS).
The cases where it could be applied, however, may be rather limited.
“Though the severity rating is high, it is relatively unlikely that this vulnerability is relevant in your environment given the double requirement of Windows nodes (much less common than Linux) and in-tree storage plugins (deprecated in favor of CSI since Kubernetes v1.14 in 2019, four years ago),” summarized KSOC, a Kubernetes-focused security advisory and remediation provider.
So what is the problem?
The CVE does not go into great detail, but it would appear to be a privilege escalation, a mismatch of creds between Windows and Linux, due to insufficient “input sanitization,” wrote Story Tweedie-Yates, KSOC vice president of marketing, in a blog post analyzing in CVE-2023-5528.
A Windows user with user admin privileges on the cluster nodes to create pods and PersistentVolumes, could also, should they explore around a bit, find access to Kubernetes components like kube-controller-manager and even the Kubelet itself, Tweedie-Yates surmised. Interfacing with the Kubernetes control plane, the Kubelet acts as the controller for the node.
And this is exactly why in-tree storage plug-ins were deprecated, in favor of the aforementioned Kubernetes Container Storage Interface (CSI), which was supported beginning in Kubernetes 1.14. Its design, among other things, offered a cleaner interface. In-tree plug-ins, however, were also supported up to the most recent Kubernetes version 1.27 (the current version is 1.28).
Kubernetes on Windows
It would be fair to say that most Kubernetes systems do not deploy Windows nodes today, though pockets of usage exist. Microsoft 365 is migrating to the Azure Container Service, for instance.
Developer deployments may also be running Windows nodes. In a 2023 StackOverflow survey, 23% of Kubernetes-using respondents utilized Windows Subsystem for Linux (WSL) for their personal computers and 22% used it professionally.
There are a number of other circumstances where Windows can get into the mix with outdated Kubernetes clusters, explained Jimmy Mesta, CTO and co-founder of KSOC, in an email to TNS.
A service account with the permissions for creating pods and Persistent Volumes could be hijacked, for instance.
“Observability in Kubernetes is very poor out of the box, so most teams do not have full visibility into who can do what in their clusters” –Jimmy Mesta, KSOC cofounder and CTO.
An organization could also be plagued with what Mesta calls “Shadow Kubernetes” or Kubernetes clusters running outside the purview of central IT management, and so may not be updated on the regular.
Bare metal deployments, in particular, may suffer from not being upgraded in a timely fashion, with the kubelet version lagging behind the overall cluster version, problematic given that it is the Kubelet that handles the in-tree plugins.
“The remediation guidance has been very specific on the Kubelet versions required to patch the issue, so if the Kubelet is accidentally left out of the upgrade it might result in unintended exposure,” Mesta writes.
Remediation
Firstly, if you are unsure if you have any Windows nodes on your system, run the command:
|
1 |
kubectl get nodes -l kubernetes.io/os=windows |
The CVE provides links to all the patches, which need to be applied to versions of kubelet v1.8.0 or later,
The CVE does not report of any exploits but notes evidence of which can be found in the audit logs. Look for PersistentVolume to create events with local path fields containing special characters.
Python programmer Tomer Peled first reported the vulnerability.
As K8s grow in usage, so will it be increasingly inspected for security holes. A month ago, three high-severity Kubernetes vulnerabilities were unearthed for the nginx ingress controller.
TNS Research Analyst Lawrence Hecht contributed to this report.
