312-50 Question 435
Single answer▪ Container TechnologyDuring an authorized security assessment, you obtain shell access inside a Linux-based Docker container running a web application. The container is started with the host Docker socket mounted at /var/run/docker.sock so the application can manage other containers. You confirm that the shell user can read and write to that socket. What is the MOST likely security impact of this misconfiguration?
- A
The attacker can use the Docker API through the mounted socket to start a privileged container or mount the host filesystem, which can lead to host-level compromise.
- B
The attacker can only affect the current container because Docker sockets enforce container-only isolation even when mounted inside a container.
- C
The attacker can intercept traffic from all other containers, but cannot execute commands on the host because the Docker socket is only for monitoring.
- D
The attacker can escape the container only if the container is running in host network mode; otherwise the Docker socket cannot be abused.
Show answer and explanation
Correct answer: A
Explanation
This scenario tests a common container security weakness: exposing the Docker daemon socket inside a container. From an attacker and CEH perspective, this is a high-risk misconfiguration because the Docker daemon typically has root-equivalent control over the host. If a compromised container can access /var/run/docker.sock, the attacker may use the Docker API to create privileged containers, mount host filesystems, or run commands in ways that bypass normal container isolation. This is why security guidance generally recommends not mounting the Docker socket into containers unless absolutely necessary, and using least-privilege alternatives where possible. Relevant references include Docker's documentation on protecting the Docker daemon socket and OWASP Docker Security guidance, both of which warn that access to the Docker daemon is equivalent to elevated control over the Docker host.
- A. Correct.
Correct. Mounting /var/run/docker.sock into a container effectively exposes the Docker Engine API to processes inside that container. If an attacker can access the socket, they may be able to create new containers with elevated privileges, bind-mount sensitive host paths such as /, or otherwise control the Docker daemon. Because the daemon typically runs with root-equivalent privileges on the host, this misconfiguration can enable host compromise.
- B. Incorrect.
Incorrect. This reflects a common misconception that container boundaries remain intact once the Docker socket is exposed. In reality, access to the Docker socket often grants broad control over the Docker daemon itself, which extends beyond the current container.
- C. Incorrect.
Incorrect. The Docker socket is not limited to monitoring. It provides management access to the Docker Engine API, which can be used to create, start, stop, inspect, and reconfigure containers. While an attacker might also impact networking indirectly, the more serious issue is control over the daemon and potential host access.
- D. Incorrect.
Incorrect. Host network mode is not required for abuse of a mounted Docker socket. The key issue is API access to the Docker daemon. Even without host networking, an attacker may launch a new privileged container, mount host directories, or otherwise leverage daemon privileges to affect the host.