The issue is ruby's `system` method which interprets args in the shell.

They should have used `popen` instead.

This is similar to python's subprocess with `shell=True`

Edit: I'm wrong!

> ls-remote has a parameter --upload-pack which can be used to execute a new shell

I don't believe this is the case.

    [1] pry(main)> system "echo", "$(whoami)"
    $(whoami)
    => true
    [2] pry(main)> system "git", "ls-remote", "--upload-pack=$(whoami)", "HEAD"
    $(whoami) 'HEAD': USERNAME: command not found
    fatal: Could not read from remote repository.

    Please make sure you have the correct access rights
    and the repository exists.
    => false

I had the same reaction as you... it looks like the vulnerability is coming from git, that's a very dangerous behavior.

I think I understand why this is happening. This is not an issue that argument parsing in git goes wrong. But instead, the `--upload-pack=` instructs git to run certain command in the remote server. In my above example (`system "git", "ls-remote", "--upload-pack=$(whoami)", "HEAD"`), HEAD is interpreted as a local file based git server. As such, the command is executed in the same machine.

I don't think so, you just forgot to add the remote server address. If you run `system "git", "ls-remote", " --upload-pack=$(touch hello) git@github.com:torvalds/linux.git", "HEAD"` it will fetch the remote server but still create the file on the local machine.

In your example, `HEAD` is the server address, which is interpreted as a local file. `$(touch hello) git@github.com:torvalds/linux.git` is the command to be run in the remote (locally in this case). It will not connect to the server in GitHub.

P.S. it seems that you have an extra space before `--upload-pack`.

Oh, that's very silly. Don't do that!

I think I understand why this happens. See https://news.ycombinator.com/item?id=26885103

It's an issue with "the UNIX way". I'm not bashing on composability, but the fact that "the UNIX way" is just composability delivered in a bloated, error prone way.

Specifically, the problem here is that git, like almost every other CLI tool, tries to add as many features as possible to make it easy to use from a console. This (coupled with the fact that these things are never documented, as is the case here, unless <exec> is some idiom I'm supposed to be aware of) makes it harder to use in a correct manor (security bugs being a subset of possible problems).