GitHub Security Advisory: GHSA-mgvv-9p9g-3jv4
Package: gix-path (RUST)
Severity: HIGH (CVSS 6.8)
CWE: CWE-427: Uncontrolled Search Path Element
Vulnerable versions: = 0.10.8
Patched in: 0.10.9

Summary: gix-path can use a fake program files location

Details:
### Summary

When looking for Git for Windows so it can run it to report its paths, `gix-path` can be tricked into running another `git.exe` placed in an untrusted location by a limited user account.

### Details

Windows permits limited user accounts without administrative privileges to create new directories in the root of the system drive. While `gix-path` first looks for `git` using a `PATH` search, in version 0.10.8 it also has a fallback strategy on Windows of checking two hard-coded paths intended to be the 64-bit and 32-bit Program Files directories:

https://github.com/Byron/gitoxide/blob/6cd8b4665bb7582f744c3244abaef812be39ec35/gix-path/src/env/git.rs#L9-L14

Existing functions, as well as the newly introduced `exe_invocation` function, were updated to make use of these alternative locations. This causes facilities in `gix_path::env` to directly execute `git.exe` in those locations, as well as to return its path or whatever configuration it reports to callers who rely on it.

Although unusual setups where the system drive is not `C:`, or even where Program Files directories have non-default names, are technically possible, the main problem arises on a 32-bit Windows system. Such a system has no `C:\Program Files (x86)` directory.

A limited user on a 32-bit Windows system can therefore create the `C:\Program Files (x86)` directory and populate it with arbitrary contents. Once a payload has been placed at the second of the two hard-coded paths in this way, other user accounts including administrators will execute it if they run an application that uses `gix-path` and do not have `git` in a `PATH` directory.

(While having `git` found in a `PATH` search prevents exploitation, merely having it installed in the default location under the real `C:\Program Files` directory does not. This is because the first hard-coded path's `mingw64` component assumes a 64-bit installation.)

### PoC

On a 32-bit (x86) Windows 10 system, with or without Git for Windows installed:

1. Create a limited user account in `lusrmgr.msc` or the Settings application.
2. Log in with that account and, using Windows Explorer or the `mkdir` command in PowerShell, create the directories `C:\Program Files (x86)\Git\mingw32\bin`. Although a limited user account cannot create regular files directly in `C:\`, it can create directories including one called `Program Files (x86)`.
3. Place a copy of `C:\Windows\system32\calc.exe` in `C:\Program Files (x86)\Git\mingw32\bin` and rename it from `calc.exe` to `git.exe`. A different test payload may be used if preferred, and the executable need not already be signed or trusted.
4. Log out, and log in as a different user. This user may be an administrator.
5. If `gitoxide` is not installed, install it. If `cargo install gitoxide` is used for the installation, then the version of `gix-path` used in the installation can be observed.
6. The vulnerability is only exploitable if `git` cannot be found in a `PATH` search. So, in PowerShell,