Symantec CWP Prevention Policies block the Docker copy command TOCTOU vulnerability TOCTOU in real world attack scenarios. The policy protections for this attack vector have been in the Docker sandbox since it was first published to Production in Early May 2017, making all versions of the CWP Docker policy offer this level of protection out of the box. Once the Docker policy is applied to your policy group, the docker host processes are restricted from writing to arbitrary locations on the host system.
Exploit Analysis and Concept Testing
The product team has reviewed website materials (https://duo.com/decipher/docker-bug-allows-root-access-to-host-file-system) and the POC code hosted on Seclists.org (https://seclists.org/oss-sec/2019/q2/131). An underlying programming bug in the code used in the Docker CLI tool’s copy file functionality allows file writes intended for containers filesystems to be redirected to the host filesystem. This allows an attack to overwrite part or all of the host filesystem when a file is copied, by running "docker cp", to or from a Malicious container. This is done by manipulating symlinks to cause a Time Of Check to Time Of Use problem. The docker cp functionality has a very small timeframe between resolving a container symlink and accessing the container path.
In this small time window an attack can replace/repoint the symlink to another location, potentially on the host filesystem. This can cause host files to be copied into containers or container files to be copied to the host. In the POC code that has been investigated, we have determined that although the "docker cp" command is invoked on the host, the process that actually performs the copy operation is the docker engine itself. One caveat here is that there is no privileged escalation aspect to this attack. The permissions required to execute the "docker cp" command are still required, as this does not allow for a way for standard/regular users to invoke the tool.
Here is a subset of the event/alert attributes captures for this exploit:
File Resource Attrs Disposition: D - Deny - This access was blocked File Path: /w00t_w00t_im_a_flag Requested Permissions: write (0x00000002) OS Result: 0x00000016 CSP Result: 0x00000000
Calling Process Attrs Process Name: /usr/bin/dockerd-ce User SID: root Process ID: 4179
The relevant items here in the event details are the fact that this is coming from a Docker Host process (/usr/bin/dockerd-ce in docker_ps), and is coming from a non-docker related path on the host filesystem. This indicates that the docker engine itself is doing something outside the bounds of its normal behavior.
The way that our policies are constructed is that we allow docker host processes to have write access to container-related resources to be able to set up mountpoints/etc. We allow docker host processes to have write access to docker host specific configuration and logging directories. There is a default rule of readonly, indicating that docker host processes do have not have permissions to write to arbitrary locations on the host filesystem. You can also see that this event is generated from the default rule – "d:171" in the Rule name Event Field. By doing this, we prevent any files intended to be written into containers, from instead being written to the host filesystem.
Subscribing will provide email updates when this Article is updated. Login is required to Subscribe