CVE-2023-3893: Insufficient input sanitization on kubernetes-csi-proxy leads to privilege escalation

[enj]

CVSS Rating: CVSS:3.1/av:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H - HIGH (8.8)

A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes running kubernetes-csi-proxy may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they include Windows nodes running kubernetes-csi-proxy.

Am I vulnerable?

Any kubernetes environment with Windows nodes that are running kubernetes-csi-proxy is impacted. This is a common default configuration on Windows nodes. Run kubectl get nodes -l kubernetes.io/os=windows to see if any Windows nodes are in use.

Affected Versions

• kubernetes-csi-proxy <= v2.0.0-alpha.0
• kubernetes-csi-proxy <= v1.1.2

How do I mitigate this vulnerability?

The provided patch fully mitigates the vulnerability and has no known side effects. Full mitigation for this class of issues requires patches applied for CVE-2023-3676, CVE-2023-3955, and CVE-2023-3893.

Outside of applying the provided patch, there are no known mitigations to this vulnerability.

Fixed Versions

• kubernetes-csi-proxy master - fixed by Ensuring all paths in powershell are passes and env vars kubernetes-csi/csi-proxy#306
• kubernetes-csi-proxy v2.0.0-alpha.1 - fixed by Cherry-pick Ensuring all paths in powershell are passes and env vars on library-development kubernetes-csi/csi-proxy#307
• kubernetes-csi-proxy v1.1.3 - fixed by Ensuring all paths in powershell are passes and env vars kubernetes-csi/csi-proxy#306

To upgrade: cordon the node, stop the associated Windows service, replace the csi-proxy.exe binary, restart the associated Windows service, and un-cordon the node. See the installation docs for more details: https://github.com/kubernetes-csi/csi-proxy#installation

If a Windows host process daemon set is used to run kubernetes-csi-proxy such as https://github.com/kubernetes-csi/csi-driver-smb/blob/master/charts/latest/csi-driver-smb/templates/csi-proxy-windows.yaml, simply upgrade the image to a fixed version such as ghcr.io/kubernetes-sigs/sig-windows/csi-proxy:v1.1.3

Detection

Kubernetes audit logs can be used to detect if this vulnerability is being exploited. Pod create events with embedded powershell commands are a strong indication of exploitation.

If you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io

Acknowledgements

This vulnerability was discovered by James Sturtevant @jsturtevant and Mark Rossetti @marosset during the process of fixing CVE-2023-3676 (that original CVE was reported by Tomer Peled @tomerpeled92)

The issue was fixed and coordinated by the fix team:

James Sturtevant @jsturtevant
Mark Rossetti @marosset
Andy Zhang @andyzhangx
Justin Terry @jterry75
Kulwant Singh @KlwntSingh
Micah Hausler @micahhausler
Rita Zhang @ritazh

and release managers:

Mauricio Poppe @mauriciopoppe

[jeremyrickard]

/area security
/kind bug
/committee security-response
/sig windows
/area kubelet

[ritazh]

/label official-cve-feed

[sshayb]

Weirdly it didn't synk with the official cve feed: "Official Kubernetes CVE List (last updated: 24 Aug 2023 11:16:31 UTC)"

[ritazh]

@sshayb the k8s CVE feed gets updated when there is a new k8s release. You should see recently announced CVEs in the feed soon. However for this particular CVE, it will not show up in the feed as this component is outside of k8s core and it is not part of the k8s release. You can get the latest releases for csi-proxy here: https://github.com/kubernetes-csi/csi-proxy/releases

[enj]

Weirdly it didn't synk with the official cve feed: "Official Kubernetes CVE List (last updated: 24 Aug 2023 11:16:31 UTC)"

@sshayb it is in the feed now.

However for this particular CVE, it will not show up in the feed as this component is outside of k8s core and it is not part of the k8s release.

@ritazh the CVE feed is purely based off of this GH search query and is unrelated to the release artifacts.

Thus it did not show up in the CVE feed because I had not closed the issue yet, which I was waiting to do until I submitted everything to mitre:

is:issue
label:official-cve-feed
state:closed
repo:kubernetes/kubernetes