In Docker through 18.06.1-ce-rc2, the API endpoints behind the 'docker cp' command are vulnerable to a symlink-exchange attack with Directory Traversal, giving attackers arbitrary read-write access to the host filesystem with root privileges, because daemon/archive.go does not do archive operations on a frozen filesystem (or from within a chroot). References: https://seclists.org/oss-sec/2019/q2/131 https://bugzilla.suse.com/show_bug.cgi?id=1096726 https://bugzilla.novell.com/show_bug.cgi?id=1096726 Upstream Patch: https://github.com/docker/docker/pull/39252 https://github.com/docker/docker/pull/5720 https://github.com/docker/docker/pull/6000
Created docker tracking bugs for this issue: Affects: fedora-all [bug 1714724]
Updating CVSS to more accurately reflect a better understanding of the attack complexity. Dropping severity to moderate accordingly.
Is an Openshift Cluster with the anyuid SCC enabled is susceptible to CVE-2018-15664?
A similar flaw was also found in podman. It has been assigned CVE-2019-10152: https://bugzilla.redhat.com/show_bug.cgi?id=1715667
Upstream PR https://github.com/moby/moby/pull/39252 has been closed in favour of https://github.com/moby/moby/pull/39292
Attack Complexity(AC) set to High(H) because the attacker cannot exploit the flaw at will, but it may require the victim user to run `docker cp` several times before the race condition is won.
Setting Privileges Required(PR) to Low(L) because an attacker needs to be able to run commands on a container and thus have some privileges there to perform the attack. Moreover, User Interaction(I) set to Required(R) because the attacker needs to wait for the user to perform a `docker cp` (probably even more than one time) to perform his attack.
External References: https://www.openwall.com/lists/oss-security/2019/05/28/1
My testing with the POC shared on the oss-security posting also reveals a ~1% success rate on hitting the race condition on run_read.sh
Upstream PR https://github.com/moby/moby/pull/39292 was merged into master branch and it seems to be the right fix for this CVE.
Mitigation: Stopping a container prior to running "docker cp" removes the TOCTOU vulnerability.
Function GetResourcePath() uses FollowSymlinkInScope(), which is used to evaluate a path within a given scope and it returns a path guaranteed to be contained in the scope at the time of the call. However, if components of the path change after the call to these functions, the guarantee does not hold anymore. Functions that use functions like ResolvePath(), GetResourcePath(), FollowSymlinkInScope() and others similar to those, may be vulnerable to a Time of Check to Time Of Use(TOCTOU) vulnerability, where the resolved path may be correctly scoped inside the container at the time of the check, but it escapes into the host filesystem at the time of use. In particular, containerArchivePath() and containerExtractToDir() are used when copying files respectively from and to a container and they are vulnerable to this flaw. An attacker who has compromised a running container could run a program to try to exploit this flaw while another privileged user is running `docker cp` to copy files from/to the container.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Extras Via RHSA-2019:1910 https://access.redhat.com/errata/RHSA-2019:1910
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2018-15664
Statement: All versions of docker prior to the fix are vulnerable to this flaw. For clarity, in the "Affected Packages State" table, we only include OpenShift Container Platform (OCP) versions 3.7 and below because for these versions docker was shipped as part of the release. For all subsequent versions of OCP until 3.11, docker is installed from the RHEL Extras repository meaning clusters will be vulnerable to the flaw unless an updated docker package has been applied. Red Hat Fuse provides only the Docker client library and is not affected by this vulnerability.