A new, high severity vulnerability was just published on Windows nodes in Kubernetes, allowing for complete access across an entire cluster. This vulnerability brings the Kubernetes CVE tally to four in 2023; the previous CVEs involved other areas of Kubernetes like the CSI driver, seccomp profile and ServiceAccount Admission Plugin, and they were rated medium or low severity. For this vulnerability, the top recommendation for protecting your environment is to install the patch.
In general, Windows has lagged behind Linux in support for Kubernetes. It was only in 2019, after three years of work, in v1.14, when production level support for Windows nodes was added to Kubernetes. Running Kubernetes on Windows nodes is still not exactly the same as running Kubernetes on Linux nodes. For example, for object permissions, Windows uses SIDs, ACLs and usernames, compared to Linux’s userIDs and groupIDs.
For the reasons above, along with others, Windows nodes are, in general, not as commonly used as Linux nodes. Though there are large services today using Windows nodes, Windows is rarely used on its own. For example, one of the biggest users of Windows in Kubernetes is the group of Microsoft services powering Office 365 and Microsoft 365, which run on Azure Kubernetes Service (AKS). But AKS itself, for other services, runs on a mix of Linux and Windows nodes.
The first vulnerability released was CVE-2023-3676, but there were two others released right after, CVE-2023-3955 and CVE-2023-3893. The vulnerabilities involve the way Kubernetes determines the location for storage of YAML config files in both the host as well as the pod.
Headlines place the cause of the vulnerability as a ‘lack of user input sanitization.’ This is what that means:
The patch that has been provided uses a technique that avoids the user input that eventually gets used as an expression in a PowerShell command. Instead, the patch provisions the input into the subPath as a string (from environmental variables).
The first thing you will want to do is find out if you are using Windows nodes, using this command:
`kubectl get nodes -l kubernetes.io/os=windows`
Since all Kubernetes versions below 1.28 are vulnerable to this CVE, installing the patch is the best option.
It is also possible, in the case of CVE-2023-3676, for Kubernetes admins to disable the use of Volume.Subpath, though this might not be ideal across an entire cluster in production, because other processes will rely on it.
You can also enforce an admission control policy that blocks certain YAML files from being implemented.
If you can identify who has system privileges, RBAC can be another layer of protection against overly permissive access to any one part of the system.
KSOC provides an admission controller that can block a malicious YAML file from being applied, and can prevent workloads from being deployed with overly permissive RBAC permissions.
Below is an example of a Rego policy that would block pod deployment if it includes the malicious subPath:
You could also set an admission control policy related to RBAC, like the one below, that prevents unnecessary usage of broad roles like cluster-admin.
In the screenshot below you can see a broad view of permissions available to users, including who can create pods, who has all privileges, and more. In this case , you could use this insight to determine who has broad access, like the kind resulting from exploitation of the vulnerability.
While Windows nodes might not be as common as Linux in Kubernetes, it is possible that some might not be aware of where the underbelly of their Kubernetes environments is Windows or Linux. This vulnerability allows for fairly easy exploitation, so it is key to check for exposure. This CVE further demonstrates the need for auditing of RBAC permissions, as well as the continued value of admission control to enforce Kubernetes Security.
Request a trial today for access to RBAC Insights, or take a product tour to see how KSOC can quickly identify the top priority risk in your Kubernetes environments.