GitHub Security Advisory: GHSA-98p4-xjmm-8mfh
Package: gix (RUST)
Severity: MODERATE (CVSS 6.4)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection'), CWE-88: Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')
Vulnerable versions: < 0.62
Patched in: 0.62

Summary: gix-transport indirect code execution via malicious username

Details:
### Summary

`gix-transport` does not check the username part of a URL for text that the external `ssh` program would interpret as an option. A specially crafted clone URL can smuggle options to SSH. The possibilities are syntactically limited, but if a malicious clone URL is used by an application whose current working directory contains a malicious file, arbitrary code execution occurs.

### Details

This is related to the patched vulnerability https://github.com/advisories/GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. Since https://github.com/Byron/gitoxide/pull/1032, `gix-transport` checks the host and path portions of a URL for text that has a `-` in a position that will cause `ssh` to interpret part of all of the URL as an option argument. But it does not check the non-mandatory username portion of the URL.

As in Git, when an address is a URL of the form `ssh://username@hostname/path`, or when it takes the special form `username@hostname:dirs/repo`, this is treated as an SSH URL. `gix-transport` will replace some characters in `username` with their `%`-based URL encodings, but otherwise passes `username@hostname` as an argument to the external `ssh` command. This happens even if `username` begins with a hyphen. In that case, `ssh` treats that argument as an option argument, and attempts to interpret and honor it as a sequence of one or more options possibly followed by an operand for the last option.

This is harder to exploit than GHSA-rrjw-j4m2-mf34, because the possibilities are constrained by:

- The difficulty of forming an option argument `ssh` accepts, given that characters such as `=`, `/`, and `\`, are URL-encoded, `:` is removed, and the argument passed to `ssh` contains the `@` sign and subsequent host identifier, which in an effective attack must be parseable as a suffix of the operand passed to the last option.

  The inability to include a literal `=` prevents the use of `-oNAME=VALUE` (e.g., `-oProxyCommand=payload`). The inability to include a literal `/` or `\` prevents smuggling in a path operand residing outside the current working directory, incuding on Windows. (Although a `~` character may be smuggled in, `ssh` does not perform its own tilde expansion, so it does not form an absolute path.)

- The difficulty, or perhaps impossibility, of completing a connection (other than when arbitrary code execution has been achieved). This complicates or altogether prevents the use of options such as `-A` and `-X` together with a connection to a real but malicious server. The reason a connection cannot generally be completed when exploiting this vulnerability is that, because the argument `gix-transport` intends as a URL is treated as an option argument, `ssh` treats the subsequent non-option argument `git-upload-pack` as the host instead of the command, but it is not a valid host name.

  Although `ssh` supports aliases for hosts, even if `git-upload-pack` could be made an alias, that is made di