A vulnerability was found in Docker engine versions before 18.09.4. A command injection due to a misinterpretation of the git ref command as a flag may lead to a remote code execution in build environments where an attacker has control over the build path issued to docker build. References: https://docs.docker.com/engine/release-notes/#18094 https://github.com/moby/moby/pull/38944
Reference: https://staaldraad.github.io/post/2019-07-16-cve-2019-13139-docker-build/
Set Confidentiality, Integrity, Availability to High (CIA:HHH) because code execution is possible. Set Attack Vector to Local (AV:L) supposing the attacker needs to pass the build path to `docker build`. Set Privileges Required to High (PR:H) as the user needs to access the docker socket to run docker commands.
The common workflow `docker build -t mycontainer .` is not affected by this flaw.
Statement: Both 1.12 and 1.13 versions of docker shipped with Red Hat Enterprise Linux Extras and OpenShift Container Platform 3 are vulnerable to this flaw, though they are less impacted than upstream. The injected command options passed to `docker build` through the docker build path are handled by `git checkout` rather than `git fetch`, which provides limited options for an attacker to exploit. It is unlikely that code execution is possible, though it cannot be ruled out entirely.
Particular attention should be paid if an attacker can provide a user-controlled build path to the `docker build` command without the need for high privileges. For examples, build environments where a user can provide a path, a URL or a git repository to build are more impacted than other environments, where the attacker is local, as the attacker will be able to elevate his privileges or possibly execute code remotely, based on the attacked environment. Assuming a local attacker, even though the command injection is possible even for a user with low privileges, the impact of that attack is just as bad as the local attacker performing regular actions with his own local user. Instead, if the attacker already has enough privileges to access the docker socket and correctly run docker commands, he would be usually able to execute code with high privileges anyway, even without this flaw.
If I can communicate with the Docker socket, then I control the system. $ docker run --privileged -v /:/host ubi8 chroot /host I am full root on your machine, and I can later do a $ docker rm CTRID Removing all records of me running the command. Being able to do a $docker build Is the least of your problems. We always recoommend that users never use the docker group on the docker.sock, so our users would not face this issue. Is there something I am missing?
Created docker tracking bugs for this issue: Affects: epel-6 [bug 1734278] Affects: fedora-all [bug 1734277] Affects: openstack-rdo [bug 1734279]
Please see comment 7. As you correctly say, if you have already enough privileges to use the docker socket, you can already do whatever you want. However, a CVE has been assigned to this issue (not by us) and it may still have an impact in some particular environments/applications where the attacker can specify just the docker-build path. For these reasons I set the Impact to Moderate.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Extras Via RHBA-2019:3092 https://access.redhat.com/errata/RHBA-2019:3092