Eliahkagan

**Name of the Vulnerable Software and Affected Versions** gitoxide versions prior to 0.17.0 **Description** The issue arises from the `gix-worktree-state` specifying 0777 permissions when checking out executable files. This is intended to be restricted by the umask, but one of the strategies used to set permissions is not subject to the umask, causing files in a repository to be world-writable in some situations. This problem affects Unix-like systems but not Windows and can lead to security issues on multi-user systems or when accounts are used to run software with reduced abilities. **Recommendations** For versions prior to 0.17.0, update to version 0.17.0 or later to resolve the issue. As a temporary workaround, consider setting `destination is initially empty` to `true` when using `gix::worktree::state::checkout` to avoid the vulnerable strategy. However, the most effective solution is to update to a version where this vulnerability is fixed.

Name of the Vulnerable Software and Affected Versions: gix-path versions prior to 0.10.11 Description: The issue concerns the improper resolution of paths containing unusual or non-ASCII characters by gix-path, which can enable a local attacker to inject configuration leading to code execution in rare cases. This occurs when gix-path attempts to find the path of a configuration file associated with the git installation using `git config -l --show-origin`. The problem arises because affected versions of gix-path do not pass `-z`/`--null` to cause `git` to report literal paths, instead attempting to parse quoted paths by stripping quotation marks, which can result in another valid but non-equivalent path. Exploitation is unlikely on single-user systems unless git has been installed in an unusual way, and it is also unlikely on multi-user systems, though plausible in uncommon configurations or use cases. Recommendations: For versions prior to 0.10.11, update to version 0.10.11 or later to resolve the issue. As a temporary workaround, consider restricting the use of the `installation config` and `installation config prefix` functions in `gix path::env` until a patch is applied. Avoid using custom `system`-scope configuration files with unusual paths or names, and ensure that `git` is installed in a standard location to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** gix-path versions prior to 0.10.10 **Description** The `gix-path` crate of the gitoxide project mistakenly treats the local repository's configuration as system-wide if no higher scoped configuration is found. This can cause a less trusted repository to be treated as more trusted, or leak sensitive information from one repository to another, such as sending credentials to another repository's remote. The issue is believed to be very difficult to exploit deliberately, due to the need to anticipate or arrange for the absence of higher-scoped configuration variables. Any operating system may be affected, but users running Apple Git on macOS are much less likely to be affected. **Recommendations** To resolve the issue, upgrade to release version 0.10.10 or later. As a temporary workaround, consider setting the `GIT CONFIG SYSTEM` and `GIT CONFIG GLOBAL` environment variables to prevent `gix-path` from finding the path of configuration files for those scopes. Additionally, using a credential manager or setting `http.<url>.extraHeader` with a specific `<url>` can help avoid the vulnerability.

**Name of the Vulnerable Software and Affected Versions** gitoxide (affected versions not specified) **Description** The `gix` and `ein` commands write pathnames and other metadata literally to terminals, even if they contain characters terminals treat specially, including ANSI escape sequences. This sometimes allows an untrusted repository to misrepresent its contents and to alter or concoct error messages. The effect is mostly an annoyance, but the author of a malicious repository who can predict how information from the repository may be accessed can cause files in the repository to be concealed or otherwise misrepresented, as well as rewrite all or part of error messages, or mimic error messages convincingly by repositioning the cursor and writing colored text. For users who do not clone or operate in clones of untrusted repositories, there is no impact. Windows is much less affected than Unix-like systems due to limitations on what characters can appear in filenames, and because traditionally Windows terminals do not support as many ANSI escape sequences. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** gitoxide versions 0.10.8 **Description** The issue arises from `gix-path` being tricked into running another `git.exe` placed in an untrusted location by a limited user account on Windows systems. Windows permits limited user accounts 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 checks two hard-coded paths intended to be the 64-bit and 32-bit Program Files directories. This causes facilities in `gix path::env` to directly execute `git.exe` in those locations. The main problem arises on a 32-bit Windows system, where a limited user can 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, 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. **Recommendations** To resolve the issue for gitoxide version 0.10.8, upgrade to release version 0.10.9, as this issue has been addressed in this version. There are no known workarounds for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** gitoxide versions prior to 0.36.0 **Description** During checkout, gitoxide does not verify that paths point to locations in the working tree. A specially crafted repository can, when cloned, place new files anywhere writable by the application. This vulnerability leads to a major loss of confidentiality, integrity, and availability. Creating files outside a working tree without attempting to execute code can directly impact integrity as well. The issue arises from the lack of verification by `gix-worktree-state` and inadequate path checks in `gix-fs` and `gix-worktree`. This allows for arbitrary code execution through the placement of files in locations where they are likely to be executed soon, such as by installing hooks in a `.git` directory. **Recommendations** Update to version 0.36.0 or later to patch the vulnerability. As a temporary workaround, consider restricting the use of `gix-worktree-state` and `gix-fs` to prevent the exploitation of this vulnerability until a patch is applied. Avoid cloning untrusted repositories to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** gitoxide (affected versions not specified) **Description** The issue is related to how gitoxide handles legacy device names on Windows. When fetching refs or checking out paths that clash with these names, it can read from or write to devices, potentially causing harm. This could lead to indefinite blocking, production of arbitrary messages, or other harmful effects under limited circumstances. The impact is expected to be limited in common configurations but may vary depending on the devices present, their usage, and the attacker's knowledge. Accessing devices through refs is less dangerous than through filenames. The greatest risk is if a command seems reasonable when a trusted application appears to recommend it, potentially misleading the user into running an attacker's command. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

Name of the Vulnerable Software and Affected Versions: gitoxide versions prior to 0.35.0 gitoxide versions prior to 0.42.0 gitoxide versions prior to 0.62.0 Description: The issue is related to the `gix-transport` component of gitoxide, which does not properly check the username part of a URL for text that the external `ssh` program would interpret as an option. This allows a specially crafted clone URL to smuggle options to SSH, potentially leading to arbitrary code execution if a malicious clone URL is used by an application whose current working directory contains a malicious file. The possibilities for exploitation are syntactically limited, but an attacker who can cause a specially named `ssh` configuration file to be placed in the current working directory can smuggle in an `-F` option referencing the file, allowing arbitrary command execution. This scenario is especially plausible because programs that operate on git repositories are often run in untrusted git repositories. Recommendations: To resolve the issue for versions prior to 0.35.0, update to version 0.35.0 or later. To resolve the issue for versions prior to 0.42.0, update to version 0.42.0 or later. To resolve the issue for versions prior to 0.62.0, update to version 0.62.0 or later. As a temporary workaround, consider restricting access to the `gix-transport` component until a patch is available. Avoid using the `gix clone` command with untrusted URLs, especially in scenarios where the current working directory may contain malicious files.

**Name of the Vulnerable Software and Affected Versions** GitPython versions prior to 3.1.41 **Description** The issue is related to the use of an untrusted search path in GitPython, a Python library for interacting with Git repositories. This could allow an attacker to execute arbitrary code with elevated privileges using a specially crafted binary file. On Windows, the vulnerability occurs when GitPython uses a shell to run `git` or when it runs `bash.exe` to interpret hooks, potentially leading to the execution of a malicious `git.exe` or `bash.exe` from an untrusted repository. **Recommendations** For versions prior to 3.1.41, update to version 3.1.41 to resolve the issue. As a temporary workaround, consider avoiding the use of shells to run `git` or interpreting hooks with `bash.exe` on Windows until the update is applied.