You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a compromised pod/container has a writable volume that maps directly to the host filesystem (Kubernetes hostPath or Docker bind mount), and you can become root inside the container, you can leverage the mount to create a setuid-root binary on the host and then execute it from the host to pop root.
28
+
29
+
Key conditions:
30
+
- The mounted volume is writable from inside the container (readOnly: false and filesystem permissions allow write).
31
+
- The host filesystem backing the mount is not mounted with the nosuid option.
32
+
- You have some way to execute the planted binary on the host (for example, separate SSH/RCE on host, a user on the host can execute it, or another vector that runs binaries from that path).
33
+
34
+
How to identify writable hostPath/bind mounts:
35
+
- With kubectl, check for hostPath volumes: kubectl get pod <pod> -o jsonpath='{.spec.volumes[*].hostPath.path}'
36
+
- From inside the container, list mounts and look for host-path mounts and test writability:
# On the host, locate the mapped path (e.g., from the Pod spec .spec.volumes[].hostPath.path or by prior enumeration)
65
+
# Example host path: /opt/limesurvey/suidbash
66
+
ls -l /opt/limesurvey/suidbash
67
+
/opt/limesurvey/suidbash -p # -p preserves effective UID 0 in bash
68
+
```
69
+
70
+
Notes and troubleshooting:
71
+
- If the host mount has nosuid, setuid bits will be ignored. Check mount options on the host (cat /proc/mounts | grep <mountpoint>) and look for nosuid.
72
+
- If you cannot get a host execution path, similar writable mounts can be abused to write other persistence/priv-esc artifacts on the host if the mapped directory is security-critical (e.g., add a root SSH key if the mount maps into /root/.ssh, drop a cron/systemd unit if maps into /etc, replace a root-owned binary in PATH that the host will execute, etc.). Feasibility depends entirely on what path is mounted.
73
+
- This technique also works with plain Docker bind mounts; in Kubernetes it’s typically a hostPath volume (readOnly: false) or an incorrectly scoped subPath.
74
+
75
+
Mitigations:
76
+
- Avoid hostPath where possible; prefer dedicated volumes.
77
+
- If hostPath is required, enforce readOnly: true and use restrictive mount options (nosuid,noexec,nodev). Apply Pod Security Standards/Admission to forbid hostPath by default.
78
+
- Run containers as non-root and drop capabilities; use SELinux/AppArmor and readOnlyRootFilesystem when possible.
79
+
- Monitor for unexpected SUID files on host and integrity changes under directories exposed to containers.
80
+
25
81
### Abusing Kubernetes Privileges
26
82
27
83
As explained in the section about **kubernetes enumeration**:
0 commit comments