Bug 1732627 (CVE-2019-13139) - CVE-2019-13139 docker: command injection due to a missing validation of the git ref command
Summary: CVE-2019-13139 docker: command injection due to a missing validation of the g...
Alias: CVE-2019-13139
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1732631 1733941 1734277 1734278 1734279
Blocks: 1732632
TreeView+ depends on / blocked
Reported: 2019-07-23 22:37 UTC by Laura Pardo
Modified: 2021-10-27 10:55 UTC (History)
35 users (show)

Fixed In Version: docker engine 18.09.4
Doc Type: If docs needed, set a value
Doc Text:
A command injection flaw was discovered in Docker during the `docker build` command. By providing a specially crafted path argument for the container to build, it is possible to inject command options to the `git fetch`/`git checkout` commands that are executed by Docker and to execute code with the privileges of the user running Docker. A local attacker who can run `docker build` with a controlled build path, or a remote attacker who has control over the docker build path, could elevate their privileges or execute code.
Clone Of:
Last Closed: 2021-10-27 10:55:32 UTC

Attachments (Terms of Use)

Description Laura Pardo 2019-07-23 22:37:45 UTC
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.


Comment 1 Riccardo Schirone 2019-07-25 16:48:33 UTC

Comment 2 Riccardo Schirone 2019-07-25 17:20:18 UTC
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.

Comment 5 Riccardo Schirone 2019-07-29 09:26:22 UTC
The common workflow `docker build -t mycontainer .` is not affected by this flaw.

Comment 6 Riccardo Schirone 2019-07-29 09:26:59 UTC

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.

Comment 7 Riccardo Schirone 2019-07-29 09:46:21 UTC
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.

Comment 10 Daniel Walsh 2019-07-29 19:15:49 UTC
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?

Comment 11 Sam Fowler 2019-07-30 06:53:26 UTC
Created docker tracking bugs for this issue:

Affects: epel-6 [bug 1734278]
Affects: fedora-all [bug 1734277]
Affects: openstack-rdo [bug 1734279]

Comment 12 Riccardo Schirone 2019-07-30 07:29:26 UTC
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.

Comment 17 Riccardo Schirone 2019-10-29 10:24:46 UTC
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

Note You need to log in before you can comment on or make changes to this bug.