4 ms·

This seems to be an issue of git. It's very surprising that a git command would invoke its arguments in shell.

tantalor 5y ago
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
- xucheng 5y ago
  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
  - deleted 5y ago
    [deleted]
  - deleted 5y ago
    [deleted]
  - tantalor 5y ago
    Oh, that's very silly. Don't do that!
    - xucheng 5y ago
      I think I understand why this happens. See https://news.ycombinator.com/item?id=26885103 https://news.ycombinator.com/item?id=26885103
  - kirby88 5y ago
    I had the same reaction as you... it looks like the vulnerability is coming from git, that's a very dangerous behavior.
    - xucheng 5y ago
      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.
      - kirby88 5y ago
        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.
        xucheng 5y ago
        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`.
qyi 5y ago
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).

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

xucheng 5y ago
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
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
- tantalor 5y ago
  Oh, that's very silly. Don't do that!
  - xucheng 5y ago
    I think I understand why this happens. See https://news.ycombinator.com/item?id=26885103 https://news.ycombinator.com/item?id=26885103
- kirby88 5y ago
  I had the same reaction as you... it looks like the vulnerability is coming from git, that's a very dangerous behavior.
  - xucheng 5y ago
    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.
    - kirby88 5y ago
      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.
      - xucheng 5y ago
        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`.

qyi 5y ago

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).