CVE-2024-45405: Gix path Gix-path Improperly Resolves Configuration Path Vulnerability

MODERATE
Advisory Identifier: GHSA-m8rp-vv92-46c7
CVSS 6.0
CWE-41
Published
Advisory Summary

CVE-2024-45405 is a MODERATE (CVSS 6.0) gix-path improperly resolves configuration path vulnerability (CWE-41: Improper Resolution of Path Equivalence) affecting Gix path libraries in the crates.io ecosystem. The issue involves gix-path improperly resolves configuration path reported by git. Remediation is available by upgrading affected packages to version 0.10.11.

CVE-2024-45405 at a Glance

CVE Identifier CVE-2024-45405
GHSA Identifier GHSA-m8rp-vv92-46c7
Severity MODERATE
CVSS v3.1 Base Score 6.0
CWE Classification CWE-41: Improper Resolution of Path Equivalence
Affected Product Gix path
Package Ecosystem crates.io
Published Date
Last Updated

Security Impact

CVSS: 6.0

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:N).

Attack Vector Local (AV:L)
Attack Complexity High (AC:H)
Privileges Required Low (PR:L)
User Interaction Required (UI:R)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity High (I:H)
Availability None (A:N)

How to Fix CVE-2024-45405

To remediate this vulnerability, upgrade all affected Gix path dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

gix-path fixed: 0.10.11
Upgrade gix-path to 0.10.11
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for gix-path

How to Check if You Are Affected

To determine whether your application is affected by CVE-2024-45405, inspect your project dependencies for Gix path:

inspect dependencies for gix-path

Analyze the terminal output to locate any version of Gix path in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.10.11), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-41: Improper Resolution of Path Equivalence, where the product is vulnerable to file system contents disclosure through path equivalence. path equivalence involves the use of special characters in file and directory names. the associated manipulations are intended to generate multiple names for the same object. In Gix path, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### Summary `gix-path` runs `git` to find the path of a configuration file associated with the `git` installation, but improperly resolves paths containing unusual or non-ASCII characters, in rare cases enabling a local attacker to inject configuration leading to code execution. ### Details In `gix_path::env`, the underlying implementation of the `installation_config` and `installation_config_prefix` functions calls `git config -l --show-origin` to find the path of a file to treat as belonging to the `git` installation. Affected versions of `gix-path` do not pass `-z`/`--null` to cause `git` to report literal paths ([`650a1b5`](https://github.com/Byron/gitoxide/commit/650a1b5cf25e086197cc55a68525a411e1c28031)). Instead, to cover the occasional case that `git` outputs a quoted path, they attempt to parse the path by stripping the quotation marks: https://github.com/Byron/gitoxide/blob/1cfe577d461293879e91538dbc4bbfe01722e1e8/gix-path/src/env/git/mod.rs#L138-L142 The problem is that, when a path is quoted, it may change in substantial ways beyond the concatenation of quotation marks. If not reversed, these changes can result in another valid path that is not equivalent to the original. This is not limited to paths with unusual characters such as quotation marks or newlines. Unless `git` is explicitly configured with `core.quotePath` set to `false`, it also happens when the path contains most non-ASCII characters, including accented or non-English letters. For example, `é` is transformed to `\303\251`, with literal backslashes. (This is an octal representation of the bytes in its UTF-8 encoding. This behavior is not limited to systems that encode paths with UTF-8 on disk.) Rarely, the configuration file `gix-path` wrongly attempts to open can be created by an attacker who has a limited user account on the system. The attacker would often need to request an account username tailored to carrying out the attack. ### PoC #### Quick demonstration on Unix On a Unix-like system in which Git supports no higher scope than `system` for configuration variables (i.e., not on macOS with Apple Git), in a locale that supports UTF-8, with `gitoxide` installed, run: ```sh mkdir myrepo cd myrepo git init printf '[real]\n\trealvar = realval\n' > 'é' printf '[fake]\n\tfakevar = fakeval\n' > '\303\251' GIT_CONFIG_SYSTEM='é' gix config ``` If the above conditions are satisfied and the `gix` command was built against an affected version of `gix-path`, then the last command's output looks something like this: ```text # From '\303\251' (GitInstallation) [fake] fakevar = fakeval # From 'é' (System) [real] realvar = realval # From '/home/ubuntu/.gitconfig' (User) [init] defaultBranch = main # From './.git/config' (Local) [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true ``` #### Demonstration across user accounts on Windows On a test system running Windows on which Git for Windows is *not* installed system-wide—resembling a scenario in which users who wish to use Git are expected to install it themselves for their accounts—create two accounts, with these usernames: - *Renée*, the target of the attack. This user may be a limited user or an administrator. Its user profile directory is assumed to be `C:\Users\Renée`. - *Ren*, the user who carries out the attack. This user should be a limited user, since an administrator would not need to exploit this vulnerability to inject configuration. Its user profile directory is assumed to be `C:\Users\Ren`. As *Ren*, run these commands in PowerShell: ```powershell $d = "$HOME\303\251e\AppData\Local\Programs\Git\etc" mkdir $d git config --file $d\gitconfig core.sshCommand calc.exe icacls $HOME\303 /grant 'Renée:(RX)' /T ``` (The `gitconfig` file can instead be written manually, in which case *Ren* need not have `git`.) As *Renée*: 1. Install Git for Windows in the default location for non-systemwide installations, which for that user account is inside `C:\Users\Renée\AppData\Local\Programs`. For a non-administrative installation, Git for Windows will pick this location automatically. Allow the installer to place the directory containing `git` in the user's `PATH`, as it does by default. (The scenario can be modified for any location the attacker can predict. So, for example, *Renée* can install Git for Windows with [`scoop`](https://scoop.sh/), and *Ren* could carry out the attack with correspondingly modified path components in place of `AppData\Local\Programs\Git`.) 2. Install `gitoxide` using any common technique, such as by [installing Rust](https://www.rust-lang.org/tools/install) and then running `cargo install gitoxide`. 3. Open a PowerShell window and run a `gix` command that attempts to run the SSH client for transport. For example: ```pwsh gix clone ssh://localhost/myrepo.git ``` At least one, and usually two, instances of the Windows calculator will pop up. This happens because `calc.exe` was configured in the fake configuration file the user *Ren* was able to cause to be used, by placing it at the location `gix-path` wrongly resolved the path of *Renée*'s own configuration file to. The `gitconfig` file written by the attacker can be adjusted with an arbitrary choice of payload, or to set other configuration variables. ### Impact On a single-user system, it is not possible to exploit this, unless `GIT_CONFIG_SYSTEM` and `GIT_CONFIG_GLOBAL` have been set to unusual values or Git has been installed in an unusual way. Such a scenario is not expected. Exploitation is unlikely even on a multi-user system, though it is plausible in some uncommon configurations or use cases. It is especially unlikely with Apple Git on macOS, due to its very high scoped configuration in `/Library` or `/Applications` that would be detected instead, as in CVE-2024-45305. The likelihood of exploitation may be higher on Windows, where attacks such as those shown in the Windows proof-of-concept above can be performed due to the status of `\` as a directory separator, and where there is no restriction on usernames containing accented or non-English letters (though the latter is also permitted on some other systems). Even then, complex user interaction is required. In most cases, a system administrator would have to approve an innocuous-seeming username, and then the targeted user (who could be the same or a different user) would have to use an application that uses `gix-path`. In general, exploitation is more likely to succeed if at least one of the following applies: - Users are expected to install `git` themselves, and are likely to do so in predictable locations. - Locations where `git` is installed, whether due to usernames in their paths or otherwise, contain characters that `git` quotes by default in paths, such as non-English letters and accented letters. - A custom `system`-scope configuration file is specified with the `GIT_CONFIG_SYSTEM` environment variable, and its path is in an unusual location or has strangely named components. - A `system`-scope configuration file is absent, empty, or suppressed by means other than `GIT_CONFIG_NOSYSTEM`. Currently, `gix-path` can treat a `global`-scope configuration file as belonging to the installation if no higher scope configuration file is available. This increases the likelihood of exploitation even on a system where `git` is installed system-wide in an ordinary way. However, exploitation is expected to be very difficult even under any combination of those factors. Although the effect here is similar to [CVE-2022-24765](https://github.com/git-for-windows/git/security/advisories/GHSA-vw2c-22j4-2fh2) once exploited, a greater degree of user interaction would usually be required, and the attack complexity here is much higher because the necessary conditions are uncommon and challenging to predict.

CVE-2024-45405 Affected Gix path Versions

1 component(s)
Fixed Versions:
0.10.11
Product / Package Ecosystem Affected Versions Fixed Version
gix-path
crates.io
< 0.10.11
0.10.11

References

Frequently Asked Questions

What is CVE-2024-45405?
CVE-2024-45405 is a security vulnerability in Gix path involving gix-path improperly resolves configuration path reported by Git under CWE-41: Improper Resolution of Path Equivalence.
Which Gix path versions are affected?
Affected versions include releases prior to 0.10.11 across affected packages: gix-path.
What version fixes CVE-2024-45405?
Upgrading to 0.10.11 (or the latest patched release for your respective branch) resolves the vulnerability.
Is gix-path affected?
Yes, gix-path is affected in releases prior to 0.10.11. Upgrade your dependency to 0.10.11 or later.
What is the CVSS score of CVE-2024-45405?
CVE-2024-45405 has a CVSS v3.1 base score of 6.0 (MODERATE) with vector string CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:N.
What CWE is associated with CVE-2024-45405?
CVE-2024-45405 is classified under CWE-41: Improper Resolution of Path Equivalence (The product is vulnerable to file system contents disclosure through path equivalence. Path equivalence involves the use of special characters in file and directory names. The associated manipulations are intended to generate multiple names for the same object.).
How can I check crates.io dependencies for CVE-2024-45405?
Run the dependency tree command: 'inspect dependencies for gix-path'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-m8rp-vv92-46c7",
  "modified" : "2024-09-18T22:48:07Z",
  "published" : "2024-09-06T19:55:24Z",
  "aliases" : [ "CVE-2024-45405" ],
  "summary" : "gix-path improperly resolves configuration path reported by Git",
  "details" : "### Summary\n\n`gix-path` runs `git` to find the path of a configuration file associated with the `git` installation, but improperly resolves paths containing unusual or non-ASCII characters, in rare cases enabling a local attacker to inject configuration leading to code execution.\n\n### Details\n\nIn `gix_path::env`, the underlying implementation of the `installation_config` and `installation_config_prefix` functions calls `git config -l --show-origin` to find the path of a file to treat as belonging to the `git` installation.\n\nAffected versions of `gix-path` do not pass `-z`/`--null` to cause `git` to report literal paths ([`650a1b5`](https://github.com/Byron/gitoxide/commit/650a1b5cf25e086197cc55a68525a411e1c28031)). Instead, to cover the occasional case that `git` outputs a quoted path, they attempt to parse the path by stripping the quotation marks:\n\nhttps://github.com/Byron/gitoxide/blob/1cfe577d461293879e91538dbc4bbfe01722e1e8/gix-path/src/env/git/mod.rs#L138-L142\n\nThe problem is that, when a path is quoted, it may change in substantial ways beyond the concatenation of quotation marks. If not reversed, these changes can result in another valid path that is not equivalent to the original.\n\nThis is not limited to paths with unusual characters such as quotation marks or newlines. Unless `git` is explicitly configured with `core.quotePath` set to `false`, it also happens when the path contains most non-ASCII characters, including accented or non-English letters. For example, `é` is transformed to `\\303\\251`, with literal backslashes. (This is an octal representation of the bytes in its UTF-8 encoding. This behavior is not limited to systems that encode paths with UTF-8 on disk.)\n\nRarely, the configuration file `gix-path` wrongly attempts to open can be created by an attacker who has a limited user account on the system. The attacker would often need to request an account username tailored to carrying out the attack.\n\n### PoC\n\n#### Quick demonstration on Unix\n\nOn a Unix-like system in which Git supports no higher scope than `system` for configuration variables (i.e., not on macOS with Apple Git), in a locale that supports UTF-8, with `gitoxide` installed, run:\n\n```sh\nmkdir myrepo\ncd myrepo\ngit init\nprintf '[real]\\n\\trealvar = realval\\n' > 'é'\nprintf '[fake]\\n\\tfakevar = fakeval\\n' > '\\303\\251'\nGIT_CONFIG_SYSTEM='é' gix config\n```\n\nIf the above conditions are satisfied and the `gix` command was built against an affected version of `gix-path`, then the last command's output looks something like this:\n\n```text\n# From '\\303\\251' (GitInstallation)\n[fake]\n        fakevar = fakeval\n\n# From 'é' (System)\n[real]\n        realvar = realval\n\n# From '/home/ubuntu/.gitconfig' (User)\n[init]\n        defaultBranch = main\n\n# From './.git/config' (Local)\n[core]\n        repositoryformatversion = 0\n        filemode = true\n        bare = false\n        logallrefupdates = true\n ```\n\n#### Demonstration across user accounts on Windows\n\nOn a test system running Windows on which Git for Windows is *not* installed system-wide—resembling a scenario in which users who wish to use Git are expected to install it themselves for their accounts—create two accounts, with these usernames:\n\n- *Renée*, the target of the attack. This user may be a limited user or an administrator. Its user profile directory is assumed to be `C:\\Users\\Renée`.\n- *Ren*, the user who carries out the attack. This user should be a limited user, since an administrator would not need to exploit this vulnerability to inject configuration. Its user profile directory is assumed to be `C:\\Users\\Ren`.\n\nAs *Ren*, run these commands in PowerShell:\n\n```powershell\n$d = \"$HOME\\303\\251e\\AppData\\Local\\Programs\\Git\\etc\"\nmkdir $d\ngit config --file $d\\gitconfig core.sshCommand calc.exe\nicacls $HOME\\303 /grant 'Renée:(RX)' /T\n```\n\n(The `gitconfig` file can instead be written manually, in which case *Ren* need not have `git`.)\n\nAs *Renée*:\n\n1. Install Git for Windows in the default location for non-systemwide installations, which for that user account is inside `C:\\Users\\Renée\\AppData\\Local\\Programs`. For a non-administrative installation, Git for Windows will pick this location automatically. Allow the installer to place the directory containing `git` in the user's `PATH`, as it does by default.\n\n   (The scenario can be modified for any location the attacker can predict. So, for example, *Renée* can install Git for Windows with [`scoop`](https://scoop.sh/), and *Ren* could carry out the attack with correspondingly modified path components in place of `AppData\\Local\\Programs\\Git`.)\n \n 2. Install `gitoxide` using any common technique, such as by [installing Rust](https://www.rust-lang.org/tools/install) and then running `cargo install gitoxide`.\n\n3. Open a PowerShell window and run a `gix` command that attempts to run the SSH client for transport. For example:\n\n    ```pwsh\n    gix clone ssh://localhost/myrepo.git\n    ```\n \n    At least one, and usually two, instances of the Windows calculator will pop up. This happens because `calc.exe` was configured in the fake configuration file the user *Ren* was able to cause to be used, by placing it at the location `gix-path` wrongly resolved the path of *Renée*'s own configuration file to.\n \n The `gitconfig` file written by the attacker can be adjusted with an arbitrary choice of payload, or to set other configuration variables.\n\n### Impact\n\nOn a single-user system, it is not possible to exploit this, unless `GIT_CONFIG_SYSTEM` and `GIT_CONFIG_GLOBAL` have been set to unusual values or Git has been installed in an unusual way. Such a scenario is not expected.\n\nExploitation is unlikely even on a multi-user system, though it is plausible in some uncommon configurations or use cases. It is especially unlikely with Apple Git on macOS, due to its very high scoped configuration in `/Library` or `/Applications` that would be detected instead, as in CVE-2024-45305.\n\nThe likelihood of exploitation may be higher on Windows, where attacks such as those shown in the Windows proof-of-concept above can be performed due to the status of `\\` as a directory separator, and where there is no restriction on usernames containing accented or non-English letters (though the latter is also permitted on some other systems). Even then, complex user interaction is required. In most cases, a system administrator would have to approve an innocuous-seeming username, and then the targeted user (who could be the same or a different user) would have to use an application that uses `gix-path`.\n\nIn general, exploitation is more likely to succeed if at least one of the following applies:\n\n- Users are expected to install `git` themselves, and are likely to do so in predictable locations.\n- Locations where `git` is installed, whether due to usernames in their paths or otherwise, contain characters that `git` quotes by default in paths, such as non-English letters and accented letters.\n- A custom `system`-scope configuration file is specified with the `GIT_CONFIG_SYSTEM` environment variable, and its path is in an unusual location or has strangely named components.\n- A `system`-scope configuration file is absent, empty, or suppressed by means other than `GIT_CONFIG_NOSYSTEM`. Currently, `gix-path` can treat a `global`-scope configuration file as belonging to the installation if no higher scope configuration file is available. This increases the likelihood of exploitation even on a system where `git` is installed system-wide in an ordinary way.\n\nHowever, exploitation is expected to be very difficult even under any combination of those factors.\n\nAlthough the effect here is similar to [CVE-2022-24765](https://github.com/git-for-windows/git/security/advisories/GHSA-vw2c-22j4-2fh2) once exploited, a greater degree of user interaction would usually be required, and the attack complexity here is much higher because the necessary conditions are uncommon and challenging to predict.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:N"
  }, {
    "type" : "CVSS_V4",
    "score" : "CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "crates.io",
      "name" : "gix-path"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.10.11"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 0.10.10"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/Byron/gitoxide/security/advisories/GHSA-m8rp-vv92-46c7"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2024-45405"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/Byron/gitoxide/commit/650a1b5cf25e086197cc55a68525a411e1c28031"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/Byron/gitoxide"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/Byron/gitoxide/blob/1cfe577d461293879e91538dbc4bbfe01722e1e8/gix-path/src/env/git/mod.rs#L138-L142"
  }, {
    "type" : "WEB",
    "url" : "https://rustsec.org/advisories/RUSTSEC-2024-0371.html"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-41" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2024-09-06T19:55:24Z",
    "nvd_published_at" : "2024-09-06T13:15:05Z"
  }
}