This project might be open to known security vulnerabilities, which can be prevented by tightening the version range of affected dependencies. Find detailed information at the bottom.
gix(45 total, 34 outdated, 5 possibly insecure)
| Crate | Required | Latest | Status |
|---|---|---|---|
| async-std | ^1.12.0 | 1.12.0 | up to date |
| document-features | ^0.2.0 | 0.2.10 | up to date |
| gix-actor | ^0.20.0 | 0.31.5 | out of date |
| gix-attributes | ^0.12.0 | 0.22.3 | out of date |
| gix-config | ^0.22.0 | 0.38.0 | out of date |
| gix-credentials | ^0.14.0 | 0.24.4 | out of date |
| gix-date | ^0.5.0 | 0.8.7 | out of date |
| gix-diff | ^0.29.0 | 0.44.1 | out of date |
| gix-discover | ^0.18.0 | 0.33.0 | out of date |
| gix-features | ^0.29.0 | 0.38.2 | out of date |
| gix-fs ⚠️ | ^0.1.1 | 0.11.2 | out of date |
| gix-glob | ^0.7.0 | 0.16.4 | out of date |
| gix-hash | ^0.11.1 | 0.14.2 | out of date |
| gix-hashtable | ^0.2.0 | 0.5.2 | out of date |
| gix-ignore | ^0.2.0 | 0.11.3 | out of date |
| gix-index ⚠️ | ^0.16.0 | 0.33.1 | out of date |
| gix-lock | ^5.0.0 | 14.0.0 | out of date |
| gix-mailmap | ^0.12.0 | 0.23.5 | out of date |
| gix-object | ^0.29.1 | 0.42.3 | out of date |
| gix-odb | ^0.45.0 | 0.61.1 | out of date |
| gix-pack | ^0.35.0 | 0.51.1 | out of date |
| gix-path | ^0.8.0 | 0.10.9 | out of date |
| gix-prompt | ^0.5.0 | 0.8.6 | out of date |
| gix-protocol | ^0.32.0 | 0.45.2 | out of date |
| gix-ref ⚠️ | ^0.29.0 | 0.45.0 | out of date |
| gix-refspec | ^0.10.1 | 0.23.1 | out of date |
| gix-revision | ^0.13.0 | 0.27.2 | out of date |
| gix-sec | ^0.8.0 | 0.10.7 | out of date |
| gix-tempfile | ^5.0.0 | 14.0.1 | out of date |
| gix-transport ⚠️ | ^0.31.0 | 0.42.2 | out of date |
| gix-traverse | ^0.25.0 | 0.39.2 | out of date |
| gix-url | ^0.18.0 | 0.27.4 | out of date |
| gix-utils | ^0.1.1 | 0.1.12 | up to date |
| gix-validate | ^0.7.4 | 0.8.5 | out of date |
| gix-worktree ⚠️ | ^0.17.0 | 0.34.1 | out of date |
| log | ^0.4.14 | 0.4.22 | up to date |
| once_cell | ^1.14.0 | 1.19.0 | up to date |
| prodash | ^23.1 | 28.0.0 | out of date |
| regex | ^1.6.0 | 1.10.5 | up to date |
| reqwest | ^0.11.13 | 0.12.5 | out of date |
| serde | ^1.0.114 | 1.0.204 | up to date |
| signal-hook | ^0.3.9 | 0.3.17 | up to date |
| smallvec | ^1.9.0 | 1.13.2 | up to date |
| thiserror | ^1.0.26 | 1.0.63 | up to date |
| unicode-normalization | ^0.1.19 | 0.1.23 | up to date |
(5 total, 1 outdated)
| Crate | Required | Latest | Status |
|---|---|---|---|
| anyhow | ^1 | 1.0.86 | up to date |
| async-std | ^1.12.0 | 1.12.0 | up to date |
| is_ci | ^1.1.1 | 1.2.0 | up to date |
| serial_test | ^2.0.0 | 3.1.1 | out of date |
| walkdir | ^2.3.2 | 2.5.0 | up to date |
gix-transport: gix-transport code execution vulnerabilityThe gix-transport crate prior to the patched version 0.36.1 would allow attackers to
use malicious ssh clone URLs to pass arbitrary arguments to the ssh program, leading
to arbitrary code execution.
PoC: gix clone 'ssh://-oProxyCommand=open$IFS-aCalculator/foo'
This will launch a calculator on OSX.
See https://secure.phabricator.com/T12961 for more details on similar vulnerabilities in git.
Thanks for vin01 for disclosing the issue.
gix-transport: gix-transport indirect code execution via malicious usernamegix-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.
The first gix crate with the fix is version 0.62.0, and the first fixed gix CLI is version 0.35. gix-transport at version v0.42 is the lowest-level plumbing crate with the fix.
This is related to the patched vulnerability RUSTSEC-2023-0064, 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 RUSTSEC-2023-0064, 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, including 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 difficult by the URL-encoding transformation.
However, an attacker who is able to cause a specially named ssh configuration file to be placed in the current working directory can smuggle in an -F option referencing the file, and this allows arbitrary command execution.
This scenario is especially plausible because programs that operate on git repositories are often run in untrusted git repositories, sometimes even to operate on another repository. Situations where this is likely, such that an attacker could predict or arrange it, may for some applications include a malicious repository with a malicious submodule configuration.
Other avenues of exploitation exist, but appear to be less severe. For example, the -E option can be smuggled to create or append to a file in the current directory (or its target, if it is a symlink). There may also be other significant ways to exploit this that have not yet been discovered, or that would arise with new options in future versions of ssh.
To reproduce the known case that facilitates arbitrary code execution, first create a file in the current directory named [email protected], of the form
ProxyCommand payload
where payload is a command with an observable side effect. On Unix-like systems, this could be date | tee vulnerable or an xdg-open, open, or other command command to launch a graphical application. On Windows, this could be the name of a graphical application already in the search path, such as calc.exe.
(Although the syntax permitted in the value of ProxyCommand may vary by platform, this is not limited to running commands in the current directory. That limitation only applies to paths directly smuggled in the username, not to the contents of a separate malicious configuration file. Arbitrary other settings may be specified in [email protected] as well.)
Then run:
gix clone 'ssh://[email protected]/abc'
Or:
gix clone -- '[email protected]:abc/def'
(The -- is required to ensure that gix is really passing the argument as a URL for use in gix-transport, rather than interpreting it as an option itself, which would not necessarily be a vulnerability.)
In either case, the payload specified in [email protected] runs, and its side effect can be observed.
Other cases may likewise be produced, in either of the above two forms of SSH addresses. For example, to create or append to the file [email protected], or to create or append to its target if it is a symlink:
gix clone 'ssh://[email protected]/abc'
gix clone -- '[email protected]:abc/def'
As in RUSTSEC-2023-0064, this would typically require user interaction to trigger an attempt to clone or otherwise connect using the malicious URL. Furthermore, known means of exploiting this vulnerability to execute arbitrary commands require further preparatory steps to establish a specially named file in the current directory. The impact is therefore expected to be lesser, though it is difficult to predict it with certainty because it is not known exactly what scenarios will arise when using the gix-transport library.
Users who use applications that make use of gix-transport are potentially vulnerable, especially:
gix-index: Traversal outside working tree enables arbitrary code executionDuring 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.
Although gix-worktree-state checks for collisions with existing files, it does not itself check if a path is really in the working tree when performing a checkout, nor do the path checks in gix-fs and gix-worktree prevent this. Cloning an untrusted repository containing specially crafted tree or blob names will create new files outside the repository, or inside the repository or a submodule's .git directory. The simplest cases are:
.. to traverse upward. This facilitates arbitrary code execution because files can be placed in one or more locations where they are likely to be executed soon..git to enter a .git directory. This facilitates arbitrary code execution because hooks can be installed.A number of alternatives that achieve the same effect are also possible, some of which correspond to specific vulnerabilities that have affected Git in the past:
/, to traverse upward or downward. For example, even without containing any tree named .. or .git, a repository can represent a file named ../outside or .git/hooks/pre-commit. This is distinct from the more intuitive case a repository containing trees that represent those paths.\, to traverse upward or downward. (Unlike /, these are valid on other systems.) See GHSA-xjx4-8694-q2fq..git..git or a case variant, with characters added that HFS+ ignores in collation. See https://github.com/git/git/commit/6162a1d323d24fd8cbbb1a6145a91fb849b2568f..git (or a case variant) by the use of NTFS stream notation, such as .git::$INDEX_ALLOCATION. See GHSA-5wph-8frv-58vj.git~1 (or a case variant). See GHSA-589j-mmg9-733v.When a checkout creates some files outside the repository directory but fails to complete, the repository directory is usually removed, but the outside files remain.
For simplicity, these examples stage a stand-in file with a valid name, modify the index, and commit. The instructions assume sed supports -i, which is the case on most systems. If using Windows, a Git Bash shell should be used.
git init dangerous-repo-installs-hook and cd into the directory..git@hooks@pre-commit, with the contents:
#!/bin/sh
printf 'Vulnerable!\n'
date >vulnerable
git add --chmod=+x .git@hooks@pre-commitenv LC_ALL=C sed -i.orig 's|\.git@hooks@pre-commit|.git/hooks/pre-commit|' .git/indexgit commit -m 'Initial commit'Then, on another or the same machine:
gix clone … command.ls -l .git/hooks to observe that the pre-commit hook is already present.git. This causes the payload surreptitiously installed as a pre-commit hook to run, printing the message Vulnerable! and creating a file in the current directory containing the current date and time.Note that the effect is not limited to modifying the current directory. The payload could be written to perform any action that the user who runs git commit is capable of.
git init dangerous-repo-reaches-up, and cd into the directory.echo 'A file outside the working tree, somehow.' >..@outsidegit add ..@outsideenv LC_ALL=C sed -i.orig 's|\.\.@outside|../outside|' .git/indexgit commit -m 'Initial commit'Then, as above, on the same or another machine, clone the repository with a gix clone … command. Observe that a file named outside is present alongside (not inside) the cloned directory.
Any use of gix or another application that makes use of gix-worktree-state, or otherwise relies on gix-fs and gix-worktree for validation, is affected, if used to clone untrusted repositories. The above description focuses on code execution, as that leads to a complete loss of confidentiality, integrity, and availability, but creating files outside a working tree without attempting to execute code can directly impact integrity as well.
In use cases where no untrusted repository is ever cloned, this vulnerability has no impact. Furthermore, the impact of this vulnerability may be lower when gix is used to clone a repository for CI/CD purposes, even if untrusted, since in such uses the environment is usually isolated and arbitrary code is usually run deliberately from the repository with necessary safeguards in place.
gix-worktree: Traversal outside working tree enables arbitrary code executionDuring 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.
Although gix-worktree-state checks for collisions with existing files, it does not itself check if a path is really in the working tree when performing a checkout, nor do the path checks in gix-fs and gix-worktree prevent this. Cloning an untrusted repository containing specially crafted tree or blob names will create new files outside the repository, or inside the repository or a submodule's .git directory. The simplest cases are:
.. to traverse upward. This facilitates arbitrary code execution because files can be placed in one or more locations where they are likely to be executed soon..git to enter a .git directory. This facilitates arbitrary code execution because hooks can be installed.A number of alternatives that achieve the same effect are also possible, some of which correspond to specific vulnerabilities that have affected Git in the past:
/, to traverse upward or downward. For example, even without containing any tree named .. or .git, a repository can represent a file named ../outside or .git/hooks/pre-commit. This is distinct from the more intuitive case a repository containing trees that represent those paths.\, to traverse upward or downward. (Unlike /, these are valid on other systems.) See GHSA-xjx4-8694-q2fq..git..git or a case variant, with characters added that HFS+ ignores in collation. See https://github.com/git/git/commit/6162a1d323d24fd8cbbb1a6145a91fb849b2568f..git (or a case variant) by the use of NTFS stream notation, such as .git::$INDEX_ALLOCATION. See GHSA-5wph-8frv-58vj.git~1 (or a case variant). See GHSA-589j-mmg9-733v.When a checkout creates some files outside the repository directory but fails to complete, the repository directory is usually removed, but the outside files remain.
For simplicity, these examples stage a stand-in file with a valid name, modify the index, and commit. The instructions assume sed supports -i, which is the case on most systems. If using Windows, a Git Bash shell should be used.
git init dangerous-repo-installs-hook and cd into the directory..git@hooks@pre-commit, with the contents:
#!/bin/sh
printf 'Vulnerable!\n'
date >vulnerable
git add --chmod=+x .git@hooks@pre-commitenv LC_ALL=C sed -i.orig 's|\.git@hooks@pre-commit|.git/hooks/pre-commit|' .git/indexgit commit -m 'Initial commit'Then, on another or the same machine:
gix clone … command.ls -l .git/hooks to observe that the pre-commit hook is already present.git. This causes the payload surreptitiously installed as a pre-commit hook to run, printing the message Vulnerable! and creating a file in the current directory containing the current date and time.Note that the effect is not limited to modifying the current directory. The payload could be written to perform any action that the user who runs git commit is capable of.
git init dangerous-repo-reaches-up, and cd into the directory.echo 'A file outside the working tree, somehow.' >..@outsidegit add ..@outsideenv LC_ALL=C sed -i.orig 's|\.\.@outside|../outside|' .git/indexgit commit -m 'Initial commit'Then, as above, on the same or another machine, clone the repository with a gix clone … command. Observe that a file named outside is present alongside (not inside) the cloned directory.
Any use of gix or another application that makes use of gix-worktree-state, or otherwise relies on gix-fs and gix-worktree for validation, is affected, if used to clone untrusted repositories. The above description focuses on code execution, as that leads to a complete loss of confidentiality, integrity, and availability, but creating files outside a working tree without attempting to execute code can directly impact integrity as well.
In use cases where no untrusted repository is ever cloned, this vulnerability has no impact. Furthermore, the impact of this vulnerability may be lower when gix is used to clone a repository for CI/CD purposes, even if untrusted, since in such uses the environment is usually isolated and arbitrary code is usually run deliberately from the repository with necessary safeguards in place.
gix-fs: Traversal outside working tree enables arbitrary code executionDuring 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.
Although gix-worktree-state checks for collisions with existing files, it does not itself check if a path is really in the working tree when performing a checkout, nor do the path checks in gix-fs and gix-worktree prevent this. Cloning an untrusted repository containing specially crafted tree or blob names will create new files outside the repository, or inside the repository or a submodule's .git directory. The simplest cases are:
.. to traverse upward. This facilitates arbitrary code execution because files can be placed in one or more locations where they are likely to be executed soon..git to enter a .git directory. This facilitates arbitrary code execution because hooks can be installed.A number of alternatives that achieve the same effect are also possible, some of which correspond to specific vulnerabilities that have affected Git in the past:
/, to traverse upward or downward. For example, even without containing any tree named .. or .git, a repository can represent a file named ../outside or .git/hooks/pre-commit. This is distinct from the more intuitive case a repository containing trees that represent those paths.\, to traverse upward or downward. (Unlike /, these are valid on other systems.) See GHSA-xjx4-8694-q2fq..git..git or a case variant, with characters added that HFS+ ignores in collation. See https://github.com/git/git/commit/6162a1d323d24fd8cbbb1a6145a91fb849b2568f..git (or a case variant) by the use of NTFS stream notation, such as .git::$INDEX_ALLOCATION. See GHSA-5wph-8frv-58vj.git~1 (or a case variant). See GHSA-589j-mmg9-733v.When a checkout creates some files outside the repository directory but fails to complete, the repository directory is usually removed, but the outside files remain.
For simplicity, these examples stage a stand-in file with a valid name, modify the index, and commit. The instructions assume sed supports -i, which is the case on most systems. If using Windows, a Git Bash shell should be used.
git init dangerous-repo-installs-hook and cd into the directory..git@hooks@pre-commit, with the contents:
#!/bin/sh
printf 'Vulnerable!\n'
date >vulnerable
git add --chmod=+x .git@hooks@pre-commitenv LC_ALL=C sed -i.orig 's|\.git@hooks@pre-commit|.git/hooks/pre-commit|' .git/indexgit commit -m 'Initial commit'Then, on another or the same machine:
gix clone … command.ls -l .git/hooks to observe that the pre-commit hook is already present.git. This causes the payload surreptitiously installed as a pre-commit hook to run, printing the message Vulnerable! and creating a file in the current directory containing the current date and time.Note that the effect is not limited to modifying the current directory. The payload could be written to perform any action that the user who runs git commit is capable of.
git init dangerous-repo-reaches-up, and cd into the directory.echo 'A file outside the working tree, somehow.' >..@outsidegit add ..@outsideenv LC_ALL=C sed -i.orig 's|\.\.@outside|../outside|' .git/indexgit commit -m 'Initial commit'Then, as above, on the same or another machine, clone the repository with a gix clone … command. Observe that a file named outside is present alongside (not inside) the cloned directory.
Any use of gix or another application that makes use of gix-worktree-state, or otherwise relies on gix-fs and gix-worktree for validation, is affected, if used to clone untrusted repositories. The above description focuses on code execution, as that leads to a complete loss of confidentiality, integrity, and availability, but creating files outside a working tree without attempting to execute code can directly impact integrity as well.
In use cases where no untrusted repository is ever cloned, this vulnerability has no impact. Furthermore, the impact of this vulnerability may be lower when gix is used to clone a repository for CI/CD purposes, even if untrusted, since in such uses the environment is usually isolated and arbitrary code is usually run deliberately from the repository with necessary safeguards in place.
gix-ref: Refs and paths with reserved Windows device names access the devicesOn Windows, fetching refs that clash with legacy device names reads from the devices, and checking out paths that clash with such names writes arbitrary data to the devices. This allows a repository, when cloned, to cause indefinite blocking or the production of arbitrary message that appear to have come from the application, and potentially other harmful effects under limited circumstances.
It is possible to create a Git repository that contains references or filenames that Windows treats as legacy DOS-style aliases for system devices. When such a repository is cloned:
gix-ref does not include a check for such names before attempting to access them on disk, which reads from the devices, though the ability to exfiltrate data appears limited.gix-worktree-state does not treat such names as collisions and instead writes to them, which writes arbitrary attacker-controlled data to the devices.Some such device names refer to devices that are often absent or inaccessible. But a few are guaranteed to be available, allowing some attacks to be carried out with low complexity. For both reading refs and writing paths, one important case is the console:
CON or CONIN$ reads data from the console, thereby blocking on console input, including in most situations where a console is not readily available. This may facilitate denial of service attacks.CON or CONOUT$ writes its contents to the console. This allows an untrusted repository to produce arbitrary text that appears to be a message from the application. Such text may facilitate social engineering if it is selected to instruct the user to perform a particular action.Another potentially important case is serial ports. For example, COM1 refers to the first serial port, if present. A malicious repository may be able to disrupt intended use of serial ports or attempt to interact with a device. In some configurations, it may be possible to interfere with the operation of a physical or virtual serial console. On Windows, local access to serial ports is often permitted even for limited user accounts without elevation.
Naming Files, Paths, and Namespaces covers most reserved names. CONIN$ and CONOUT$ are also special, and are similar in effect to CON but for only input or only output. These names are case-insensitive and can also be accessed with file extensions (e.g, CON.txt is equivalent to CON) and with some variations involving added spaces or colons.
Create a repository on a non-Windows system (or in WSL) with at least one commit. Use git tag CON to create a lightweight tag named CON. Place the repository somewhere it can be cloned on Windows. A file:// URL is sufficient for testing if a private remote is unavailable. If using git push, pass --tags so the remote has the tag.
On a Windows system, clone the repository with gix clone. This command will block immediately, reading input from the console. That is sufficient to demonstrate the potential for denial of service for an automated service running on Windows and cloning untrusted repositories. The experiment can be stopped with Ctrl+C.
However, if desired, input can be provided. Ending input with Ctrl+Z followed by Enter will cause it to be passed to the application. This will lead to an error message, the specific details of which vary by whether the input is empty or nonempty, and whether it matches or does not match the hexadecimal hash of the tagged commit.
Create a repository on a non-Windows system (or in WSL) and commit a file named CON with the contents:
warning: data loss imminent; you should run EVIL_COMMAND to back up your work!
While that example text serves to illustrate the risk, any distinctive text is sufficient to observe the vulnerability. Place the repository somewhere it can be cloned on Windows. As above, a file:// URL is sufficient.
On a Windows system, clone the repository with gix clone. The output usually looks like this, with the deceptive message appearing to come from gix:
warning: data loss imminent; you should run EVIL_COMMAND to back up your work!
04:45:15 indexing done 3.0 objects in 0.00s (12.1K objects/s)
04:45:15 decompressing done 309B in 0.00s (1.2MB/s)
04:45:15 Resolving done 3.0 objects in 0.05s (58.0 objects/s)
04:45:15 Decoding done 309B in 0.05s (6.0KB/s)
04:45:15 writing index file done 1.2KB in 0.00s (7.0MB/s)
04:45:15 create index file done 3.0 objects in 0.05s (55.0 objects/s)
04:45:15 read pack done 294B in 0.05s (5.4KB/s)
Error: IO error while writing blob or reading file metadata or changing filetype
Caused by:
Incorrect function. (os error 1)
The exact placement of the message is nondeterministic. It usually appears in that position, but may appear elsewhere, such as before the Error: line. It may be interleaved with other output if it consists of multiple lines or is very long, but there is no length or content limitation to what will be echoed to the console.
If Windows is not used, or untrusted repositories are not cloned or otherwise used, then there is no impact.
The impact is expected to be limited in common configurations, but may vary widely depending on what devices exist, how they are being used, how much knowledge an attacker has of the precise details of their use, and whether the user is likely to trust information that appears in a console. Accessing devices through refs is expected to be less dangerous than accessing them through filenames, since it is trivial to attempt to write arbitrary data using filenames.
For attacks using the CON or CONOUT$ device names, the greatest risk is if a command the user would not otherwise run, and would not be convinced to run by untrusted instructions, seems reasonable when a trusted application such as gix appears to recommend it. The user may then be misled into running an attacker's command.
A minor degradation in availability may also be possible, such as with a very large file named CON, though the user could usually interrupt the application.
gix-index: Refs and paths with reserved Windows device names access the devicesOn Windows, fetching refs that clash with legacy device names reads from the devices, and checking out paths that clash with such names writes arbitrary data to the devices. This allows a repository, when cloned, to cause indefinite blocking or the production of arbitrary message that appear to have come from the application, and potentially other harmful effects under limited circumstances.
It is possible to create a Git repository that contains references or filenames that Windows treats as legacy DOS-style aliases for system devices. When such a repository is cloned:
gix-ref does not include a check for such names before attempting to access them on disk, which reads from the devices, though the ability to exfiltrate data appears limited.gix-worktree-state does not treat such names as collisions and instead writes to them, which writes arbitrary attacker-controlled data to the devices.Some such device names refer to devices that are often absent or inaccessible. But a few are guaranteed to be available, allowing some attacks to be carried out with low complexity. For both reading refs and writing paths, one important case is the console:
CON or CONIN$ reads data from the console, thereby blocking on console input, including in most situations where a console is not readily available. This may facilitate denial of service attacks.CON or CONOUT$ writes its contents to the console. This allows an untrusted repository to produce arbitrary text that appears to be a message from the application. Such text may facilitate social engineering if it is selected to instruct the user to perform a particular action.Another potentially important case is serial ports. For example, COM1 refers to the first serial port, if present. A malicious repository may be able to disrupt intended use of serial ports or attempt to interact with a device. In some configurations, it may be possible to interfere with the operation of a physical or virtual serial console. On Windows, local access to serial ports is often permitted even for limited user accounts without elevation.
Naming Files, Paths, and Namespaces covers most reserved names. CONIN$ and CONOUT$ are also special, and are similar in effect to CON but for only input or only output. These names are case-insensitive and can also be accessed with file extensions (e.g, CON.txt is equivalent to CON) and with some variations involving added spaces or colons.
Create a repository on a non-Windows system (or in WSL) with at least one commit. Use git tag CON to create a lightweight tag named CON. Place the repository somewhere it can be cloned on Windows. A file:// URL is sufficient for testing if a private remote is unavailable. If using git push, pass --tags so the remote has the tag.
On a Windows system, clone the repository with gix clone. This command will block immediately, reading input from the console. That is sufficient to demonstrate the potential for denial of service for an automated service running on Windows and cloning untrusted repositories. The experiment can be stopped with Ctrl+C.
However, if desired, input can be provided. Ending input with Ctrl+Z followed by Enter will cause it to be passed to the application. This will lead to an error message, the specific details of which vary by whether the input is empty or nonempty, and whether it matches or does not match the hexadecimal hash of the tagged commit.
Create a repository on a non-Windows system (or in WSL) and commit a file named CON with the contents:
warning: data loss imminent; you should run EVIL_COMMAND to back up your work!
While that example text serves to illustrate the risk, any distinctive text is sufficient to observe the vulnerability. Place the repository somewhere it can be cloned on Windows. As above, a file:// URL is sufficient.
On a Windows system, clone the repository with gix clone. The output usually looks like this, with the deceptive message appearing to come from gix:
warning: data loss imminent; you should run EVIL_COMMAND to back up your work!
04:45:15 indexing done 3.0 objects in 0.00s (12.1K objects/s)
04:45:15 decompressing done 309B in 0.00s (1.2MB/s)
04:45:15 Resolving done 3.0 objects in 0.05s (58.0 objects/s)
04:45:15 Decoding done 309B in 0.05s (6.0KB/s)
04:45:15 writing index file done 1.2KB in 0.00s (7.0MB/s)
04:45:15 create index file done 3.0 objects in 0.05s (55.0 objects/s)
04:45:15 read pack done 294B in 0.05s (5.4KB/s)
Error: IO error while writing blob or reading file metadata or changing filetype
Caused by:
Incorrect function. (os error 1)
The exact placement of the message is nondeterministic. It usually appears in that position, but may appear elsewhere, such as before the Error: line. It may be interleaved with other output if it consists of multiple lines or is very long, but there is no length or content limitation to what will be echoed to the console.
If Windows is not used, or untrusted repositories are not cloned or otherwise used, then there is no impact.
The impact is expected to be limited in common configurations, but may vary widely depending on what devices exist, how they are being used, how much knowledge an attacker has of the precise details of their use, and whether the user is likely to trust information that appears in a console. Accessing devices through refs is expected to be less dangerous than accessing them through filenames, since it is trivial to attempt to write arbitrary data using filenames.
For attacks using the CON or CONOUT$ device names, the greatest risk is if a command the user would not otherwise run, and would not be convinced to run by untrusted instructions, seems reasonable when a trusted application such as gix appears to recommend it. The user may then be misled into running an attacker's command.
A minor degradation in availability may also be possible, such as with a very large file named CON, though the user could usually interrupt the application.
gix-worktree: Refs and paths with reserved Windows device names access the devicesOn Windows, fetching refs that clash with legacy device names reads from the devices, and checking out paths that clash with such names writes arbitrary data to the devices. This allows a repository, when cloned, to cause indefinite blocking or the production of arbitrary message that appear to have come from the application, and potentially other harmful effects under limited circumstances.
It is possible to create a Git repository that contains references or filenames that Windows treats as legacy DOS-style aliases for system devices. When such a repository is cloned:
gix-ref does not include a check for such names before attempting to access them on disk, which reads from the devices, though the ability to exfiltrate data appears limited.gix-worktree-state does not treat such names as collisions and instead writes to them, which writes arbitrary attacker-controlled data to the devices.Some such device names refer to devices that are often absent or inaccessible. But a few are guaranteed to be available, allowing some attacks to be carried out with low complexity. For both reading refs and writing paths, one important case is the console:
CON or CONIN$ reads data from the console, thereby blocking on console input, including in most situations where a console is not readily available. This may facilitate denial of service attacks.CON or CONOUT$ writes its contents to the console. This allows an untrusted repository to produce arbitrary text that appears to be a message from the application. Such text may facilitate social engineering if it is selected to instruct the user to perform a particular action.Another potentially important case is serial ports. For example, COM1 refers to the first serial port, if present. A malicious repository may be able to disrupt intended use of serial ports or attempt to interact with a device. In some configurations, it may be possible to interfere with the operation of a physical or virtual serial console. On Windows, local access to serial ports is often permitted even for limited user accounts without elevation.
Naming Files, Paths, and Namespaces covers most reserved names. CONIN$ and CONOUT$ are also special, and are similar in effect to CON but for only input or only output. These names are case-insensitive and can also be accessed with file extensions (e.g, CON.txt is equivalent to CON) and with some variations involving added spaces or colons.
Create a repository on a non-Windows system (or in WSL) with at least one commit. Use git tag CON to create a lightweight tag named CON. Place the repository somewhere it can be cloned on Windows. A file:// URL is sufficient for testing if a private remote is unavailable. If using git push, pass --tags so the remote has the tag.
On a Windows system, clone the repository with gix clone. This command will block immediately, reading input from the console. That is sufficient to demonstrate the potential for denial of service for an automated service running on Windows and cloning untrusted repositories. The experiment can be stopped with Ctrl+C.
However, if desired, input can be provided. Ending input with Ctrl+Z followed by Enter will cause it to be passed to the application. This will lead to an error message, the specific details of which vary by whether the input is empty or nonempty, and whether it matches or does not match the hexadecimal hash of the tagged commit.
Create a repository on a non-Windows system (or in WSL) and commit a file named CON with the contents:
warning: data loss imminent; you should run EVIL_COMMAND to back up your work!
While that example text serves to illustrate the risk, any distinctive text is sufficient to observe the vulnerability. Place the repository somewhere it can be cloned on Windows. As above, a file:// URL is sufficient.
On a Windows system, clone the repository with gix clone. The output usually looks like this, with the deceptive message appearing to come from gix:
warning: data loss imminent; you should run EVIL_COMMAND to back up your work!
04:45:15 indexing done 3.0 objects in 0.00s (12.1K objects/s)
04:45:15 decompressing done 309B in 0.00s (1.2MB/s)
04:45:15 Resolving done 3.0 objects in 0.05s (58.0 objects/s)
04:45:15 Decoding done 309B in 0.05s (6.0KB/s)
04:45:15 writing index file done 1.2KB in 0.00s (7.0MB/s)
04:45:15 create index file done 3.0 objects in 0.05s (55.0 objects/s)
04:45:15 read pack done 294B in 0.05s (5.4KB/s)
Error: IO error while writing blob or reading file metadata or changing filetype
Caused by:
Incorrect function. (os error 1)
The exact placement of the message is nondeterministic. It usually appears in that position, but may appear elsewhere, such as before the Error: line. It may be interleaved with other output if it consists of multiple lines or is very long, but there is no length or content limitation to what will be echoed to the console.
If Windows is not used, or untrusted repositories are not cloned or otherwise used, then there is no impact.
The impact is expected to be limited in common configurations, but may vary widely depending on what devices exist, how they are being used, how much knowledge an attacker has of the precise details of their use, and whether the user is likely to trust information that appears in a console. Accessing devices through refs is expected to be less dangerous than accessing them through filenames, since it is trivial to attempt to write arbitrary data using filenames.
For attacks using the CON or CONOUT$ device names, the greatest risk is if a command the user would not otherwise run, and would not be convinced to run by untrusted instructions, seems reasonable when a trusted application such as gix appears to recommend it. The user may then be misled into running an attacker's command.
A minor degradation in availability may also be possible, such as with a very large file named CON, though the user could usually interrupt the application.