Breaking Docker's Named Pipes SYSTEMatically by Eviatar Gerzi

### Overview In this talk presented at Insomniac, security researcher Eviatar Gerzi shares findings from an assessment into Docker Desktop on Windows and Windows containers. While Docker Desktop relies on several processes to run containers, it introduces an architectural attack surface between low-privileged user-facing components (such as the GUI) and privileged backend services like `com.docker.service`, which runs as `SYSTEM`. Communication across this boundary is handled via Windows named pipes, exposing undocumented REST-like endpoints that can be systematically abused by local users.

### Key Topics - **Docker for Windows Architecture**: Breakdown of components including the Docker Desktop GUI, `dockerd`, and the Windows-specific privileged `com.docker.service` communicating via approximately 40 named pipes. - **Implicit Privileged Group (`docker-users`)**: Analysis of the `docker-users` group, which Docker treats as unprivileged, but functionally grants administrative and `SYSTEM` compromise capabilities. - **Named Pipe REST API Exposure**: Discovery of an undocumented HTTP client / REST API exposed over named pipes (`dockerBackendV2`) by `com.docker.service`. - **Privilege Escalation Primitives**: Leveraging exposed APIs (`moveDataFolder`, `daemon.json` configuration, `pidfile`, and Hyper-V controller methods) to achieve arbitrary file writes, moves, and deletions, which are escalated to `SYSTEM` code execution using junction and symlink techniques.

### Technical Details Gerzi identified that Windows containers inherently allow local privilege escalation to `SYSTEM` by design: a low-privileged user in `docker-users` can mount a protected host directory (such as `C:\Windows`) inside a container and modify host files directly from within the container. When reported, Docker stated this behavior was outside their control and suggested the `--no-windows-containers` flag.

Beyond this by-design limitation, the researcher analyzed the named pipe `dockerBackendV2` created by `ResolvePipeAsync` in `com.docker.service` dependency DLLs (`Docker.Core` and `Docker.Backend`), exposing REST API endpoints reachable by `docker-users`: - **`moveDataFolder` Abuse**: Intended to move Docker VHDX data directories with `SYSTEM` privileges. While constrained by checks looking for `docker-desktop.vhdx`, subdirectories move all contents. Moving files across the same volume retains original low-privileged permissions. By combining directory junctions, James Forshaw's Object Manager symbolic links, and print spooler DLL hijacking (triggered without reboot via network service privilege escalation techniques documented by Alex Ionescu and Yarden Shafir), Gerzi gained an interactive `SYSTEM` shell on Windows 11. - **`daemon.json` Start/Stop Configuration Manipulation**: - **`data-root`**: Setting the Docker data directory allows redirecting where configuration databases like `local-kv.db` are created. Exploiters can win a TOCTOU race condition by substituting a junction and symlink before file creation, yielding arbitrary file overwrite. - **`pidfile`**: Docker writes its process ID to a specified path on service start and deletes it on service stop using `DeleteFileW`. By targeting empty directory deletion (via `::$INDEX_ALLOCATION`) alongside Zero Day Initiative research (targeting `C:\Config.Msi` and malicious rollback scripts/HID DLL hijacking via on-screen keyboard `osk.exe`), arbitrary file deletion was turned into local privilege escalation. - **Hyper-V Controller**: Methods `Create` and `Destroy` in the Hyper-V controller were similarly vulnerable to junction/symlink redirection, providing arbitrary file creation/overwrite and deletion primitives.

To aid research, Gerzi developed and referenced an inspection utility called `PipeViewer` to enumerate and audit named pipe permissions across Windows.

### Takeaways Exposing rich, privileged REST-like APIs over Windows named pipes dramatically widens the local attack surface. Granting non-administrator accounts membership in the `docker-users` group effectively provides local administrative and `SYSTEM` equivalence on Windows hosts through built-in container volume mounting as well as flaws in Docker Desktop's backend services.