CVE-2024-32884

gitoxide is a pure Rust implementation of Git. 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. This is related to the patched vulnerability GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. This issue has been patched in versions 0.35.0, 0.42.0 and 0.62.0.

gitoxide is a pure Rust implementation of Git. 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. This is related to the patched vulnerability GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. This issue has been patched in versions 0.35.0, 0.42.0 and 0.62.0.

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 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…

gitoxide is a pure Rust implementation of Git. 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. This is related to the patched vulnerability GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. This issue has been patched in versions 0.35.0, 0.42.0 and 0.62.0.

gitoxide is a pure Rust implementation of Git. 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. This is related to the patched vulnerability GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. This issue has been patched in versions 0.35.0, 0.42.0 and 0.62.0.

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 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…

gitoxide is a pure Rust implementation of Git. 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. This is related to the patched vulnerability GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. This issue has been patched in versions 0.35.0, 0.42.0 and 0.62.0.

gitoxide is a pure Rust implementation of Git. 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. This is related to the patched vulnerability GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. This issue has been patched in versions 0.35.0, 0.42.0 and 0.62.0.

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.

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.

Details

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…