Impact Analysis

This vulnerability can be exploited to perform persistent denial-of-service attacks on the host system.

• Convert critical system files (e.g., /etc/docker/daemon.json) into directories to prevent service restarts.
• Create files like /etc/nologin to block user logins.
• Overwrite system paths with empty files to disrupt services.

Exploitation requires a running container with a process capable of rapidly creating and swapping symlinks at a volume mount destination, combined with an operator initiating `docker cp` or calling the affected API endpoints.

Containers without volume mounts are not affected.

Useful 0 Not Useful 0

Executive Summary

This vulnerability is a race condition in Docker's `docker cp` command and related archive API endpoints that allows a malicious container to create empty files or directories at arbitrary absolute paths on the host filesystem.

It happens during the setup of bind-mount volumes when the Docker daemon resolves a mount destination path inside the container and then creates the mountpoint. Between resolving the path and creating it, a container process can swap a path component with a symlink pointing to a host location.

Because the creation functions follow symlinks in intermediate path components, the file or directory is created outside the container root with root privileges, allowing the container to escape its filesystem boundaries.

Useful 0 Not Useful 0

Detection Guidance

Detection of this vulnerability involves monitoring for suspicious activity related to the creation of empty files or directories at arbitrary absolute paths on the host filesystem by containers.

Since exploitation requires a running container with volume mounts and rapid creation and swapping of symlinks combined with use of the `docker cp` command or related archive API endpoints, detection can focus on:

• Monitoring usage of the `docker cp` command and API calls to PUT /containers/{id}/archive and HEAD /containers/{id}/archive.
• Checking for unexpected empty files or directories created at absolute paths on the host, especially critical system paths like /etc/docker/daemon.json or /etc/nologin.
• Inspecting container volume mount points for symlink swaps or unusual symlink activity.

Suggested commands to help detect suspicious files or directories on the host filesystem include:

• Find recently created empty files or directories: `find / -type f -empty -o -type d -empty -exec ls -ld {} \;`
• Check for suspicious symlinks in mount paths: `find /path/to/volume/mounts -type l -ls`
• Audit docker cp usage by reviewing shell history or docker daemon logs for commands or API calls related to copying archives.

Useful 0 Not Useful 0

Mitigation Strategies

Immediate mitigation steps include:

• Upgrade Docker Engine to version 29.5.1 or later, or Moby Daemon to version 2.0.0-beta.14 or later, where the vulnerability is patched.
• Avoid running untrusted containers, especially those that have volume mounts.
• Avoid using the `docker cp` command or the affected archive API endpoints with untrusted containers.
• Restrict access to the archive API endpoints (PUT /containers/{id}/archive, HEAD /containers/{id}/archive) using authorization plugins or other access control mechanisms.

Useful 0 Not Useful 0

Compliance Impact

This vulnerability allows a malicious container to create empty files or directories at arbitrary absolute paths on the host filesystem, potentially disrupting critical system files and services. While it impacts system integrity and availability, it does not expose or allow unauthorized read/write access to existing files or data.

Because the vulnerability can lead to denial-of-service conditions by preventing service restarts or blocking logins, it may indirectly affect compliance with standards like GDPR or HIPAA that require maintaining system availability and integrity.

However, since it does not result in unauthorized disclosure or modification of sensitive data, the direct impact on data privacy regulations such as GDPR or HIPAA is limited.

Organizations relying on Docker or Moby should consider this vulnerability in their risk assessments and ensure timely patching to maintain compliance with availability and integrity requirements of common standards.

Useful 0 Not Useful 0