In Git LFS version 3.0, we added support for understanding the
GIT_SSH_VARIANT environment variable and its corresponding configuration
option. When we did so, we dropped the special-casing for program names
and instead always used the -- setting for the default variant, "ssh".
This variant represents OpenSSH, which as a program with normal POSIX
option handling, supports -- just fine.
Unfortunately, not all clients do. TeamCity's SSH client doesn't set
the variant and also doesn't understand --. We need to handle this case
to prevent option injection in case someone tries to use a URL like
"ssh://-oProxyCommand=exploit/", which could otherwise lead to arbitrary
code execution.
However, we don't have to add this all the time, but only when the
user-and-host portion starts with a dash. The reason is that the only
other place an attacker could inject an option is in the path, and the
path is not a separate option by itself. The path is always preceded by
a command (either "git-lfs-authenticate" or "git-lfs-transfer" in a
single option that contains the name of the command, the path, and the
operation, separated by spaces. As a result, option injection is not
possible in the path since those commands don't take options.
Note that Git just dies in this case with a message like so:
fatal: strange hostname '-oProxyCommand=exploit' blocked
Let's adopt this approach of using -- less often so that we can more
gracefully deal with this case and fix some SSH clients, even if they
really should learn to understand this option. Update the test binary
to expect the new results as well.
Since we're adjusting the end-of-options delimiter such that it's only
used for the default SSH variant and, in particular, only when the
user/host parameter starts with a "-" character, we still need to accept
that command argument format in our lfs-ssh-echo test helper program, so
we keep that logic, but also simplify our logic for parsing the
program's arguments so it will be, with luck, easier to maintain in the
future.
Note that we also remove the "$4" from one error message
because it's no longer the case that that error condition
always arises due to the fourth argument.
Co-authored-by: Chris Darroch <chrisd8088@github.com>
a106dcb1e0