T05 · Unauthorized Access and Privilege Escalation
Error
- Location
- SKILL.md:133
- Finding
- Unrestricted Docker Socket Exposure Grants Effective Host Control## Vulnerability Details **File Location**: `SKILL.md:133` **Vulnerability Type**: Docker daemon socket exposed to a container **Risk Level**: Critical **Vulnerable Code**: ```bash docker run -d --name portainer -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock -v portainer-data:/data --restart unless-stopped portainer/portainer-ce:latest ``` ### Technical Analysis The deployment command mounts the host Docker daemon socket directly into the Portainer container. Access to `/var/run/docker.sock` generally provides control over the Docker daemon and is functionally equivalent to root-level host access. A process controlling the socket can create privileged containers, mount arbitrary host directories, access secrets stored in other containers, alter running workloads, and modify host files through bind mounts. The risk is compounded because Portainer is published on all host interfaces and uses a mutable `latest` image tag. ### Attack Path 1. An attacker reaches the Portainer service through TCP port `9000`. 2. The attacker exploits a Portainer vulnerability, compromises an administrator account, or abuses an insecure initial configuration. 3. The compromised service communicates with the mounted Docker socket. 4. The attacker creates a privileged container or one that bind-mounts the host root filesystem. 5. The attacker reads or modifies host files, extracts credentials, accesses other containers, or establishes host-level control. ### Impact Assessment Successful exploitation can provide effective root-level control of the Docker host. The affected scope includes host files, Docker-managed secrets and volumes, all containers controlled by the daemon, attached networks, and data reachable from the host.
- Remediation
- ## Remediation Suggestions - Do not mount the raw Docker socket unless it is strictly necessary. - Prefer a restricted Docker socket proxy that exposes only the minimum API operations required by Portainer. - Run management interfaces on a dedicated administrative network and bind them to a trusted address rather than all interfaces. - Require strong authentication, protect initial setup, and place the interface behind TLS and network allowlisting. - Pin the Portainer image to a reviewed version and immutable digest. - Apply defense-in-depth controls such as a read-only root filesystem, dropped Linux capabilities, `no-new-privileges`, and host firewall rules. - Monitor Docker daemon API activity for unexpected privileged-container creation and host bind mounts.