312-50 Question 437
Single answer▪ Container TechnologyDuring an authorized assessment of a Linux host running Docker, you discover a web application container started with the Docker socket mounted from the host as /var/run/docker.sock. The container is running as root, and the application has a command-injection flaw that gives you shell access inside the container. Which action would MOST directly allow you to gain control of the underlying host from inside that compromised container?
- A
Use the mounted Docker socket to start a new privileged container with the host filesystem mounted, then access the host through that mount
- B
Exploit ARP spoofing from inside the container to poison the host's network stack and obtain root on the host
- C
Read environment variables from the current container to automatically inherit root privileges on the host kernel
- D
Restart the current container repeatedly until Docker falls back to running commands directly on the host
Show answer and explanation
Correct answer: A
Explanation
The key issue is the mounted Docker socket, /var/run/docker.sock. Docker's UNIX socket provides access to the Docker API, and access to that API is effectively equivalent to root on the host in many environments because it allows an operator to create containers with powerful configurations. In a real-world attack path, a tester who gains command execution inside a container with the Docker socket exposed can often launch another container with elevated privileges, bind-mount the host filesystem, and then interact with the host directly. This is why security guidance consistently warns against mounting the Docker socket into untrusted containers. Relevant best-practice references include Docker's security guidance and industry container hardening recommendations, which advise minimizing daemon exposure, avoiding privileged containers, restricting socket access, and using least privilege. From a CEH perspective, this question tests the candidate's ability to recognize a practical container escape path caused by insecure runtime configuration rather than a kernel exploit.
- A. Correct.
Correct. If /var/run/docker.sock is mounted into a container and an attacker can interact with it, they can control the Docker daemon on the host. Since the Docker daemon typically runs with root-equivalent privileges, the attacker can create a new container with elevated settings such as --privileged and mount the host filesystem (for example, mounting / from the host into the new container). From there, they can modify host files, access sensitive data, or chroot into the host filesystem. This is a well-known container breakout risk and is why exposing the Docker socket to containers is considered highly dangerous.
- B. Incorrect.
Incorrect. ARP spoofing may enable man-in-the-middle attacks on a local network segment, but it does not directly grant root access to the Docker host. The scenario already provides a much more direct path to host compromise through the exposed Docker socket. Choosing this option reflects a misunderstanding between network-layer attacks and Docker daemon control.
- C. Incorrect.
Incorrect. Environment variables inside a container may reveal secrets such as API keys or credentials, but they do not automatically confer root privileges on the host. Containers share the host kernel, but being root inside a standard container is not the same as being root on the host unless additional dangerous configurations, such as access to the Docker socket or privileged mode, are present.
- D. Incorrect.
Incorrect. Docker does not 'fall back' to executing container commands directly on the host because a container restarts multiple times. Restart policies may relaunch the container, but this behavior does not bypass container isolation or grant host-level execution. This option is a plausible-sounding but false assumption about Docker runtime behavior.