How Tiny Docker Misconfigurations Can Compromise CI Build Environments

Why DevOps and Docker Are Popular

DevOps combines Development and Operations, allowing developers to focus on code while operations handle deployment. Before Docker, teams had to set up full database environments; Docker lets them build custom images from lightweight base images, making CI pipelines faster and more reproducible.

Typical Build Environments

Common multi‑tenant build setups include fully managed services such as AWS CodeBuild, Docker build services that run containers, and Docker‑in‑Docker (Dind) where a Docker daemon runs inside a container. Dind creates two containers an attacker must escape, while CodeBuild reduces the attack surface by providing a fresh, isolated container for each build.

How Attackers Can Control the Build Process

Build pipelines start by creating a Git repository that is packaged and transferred to the build environment. Containers are configured via a Dockerfile or a CI configuration file (e.g., config-ci.yml) that is later transformed into a Dockerfile. By modifying the relative path of the Dockerfile in config-ci.yml, an attacker can perform directory‑traversal attacks.

Attacking the Pre‑Build Process

Changing the build directory in config-ci.yml triggers errors that leak filesystem paths. The attacker can then read files, parse Docker daemon error messages, and attempt symlink attacks, though Docker blocks inclusion of files outside the build context.

Exploiting Dind and the Docker Daemon

Each step of a Docker build runs in a new container, but when Dind is used, the inner container shares the host’s Docker daemon via the host socket. The daemon is often started with --host=tcp://0.0.0.0:2375, exposing it on all interfaces and allowing containers to communicate over the default Docker network, creating a network‑level vulnerability.

Implementing Dockerfile Attacks

By supplying a malicious Dockerfile that installs docker and netcat, copies the source code into the build container, creates a device node with mknod, and launches a reverse shell, the attacker can gain interactive access to the build container and, subsequently, to the host Docker daemon.

Stack Handling and Privilege Escalation

After obtaining a shell inside the temporary build container, the attacker can use the host Docker socket to launch a privileged container with --net=host and -v /:/vhost, gaining access to the underlying CodeBuild host’s filesystem and network.

Mitigation Measures

Fixes are straightforward: never bind the Docker daemon to all interfaces, remove the --host=tcp://0.0.0.0:2375 line from wrapper scripts, and rely on the Unix socket ( --host=unix:///var/run/docker.sock) for local communication.

Conclusion

Container policies provide a solid mechanism for safely running untrusted code, but their security depends on correct configuration. Default settings are safe, yet a single misconfiguration can collapse the entire security model, exposing the host and sensitive credentials.