mirror of https://github.com/rust-lang/cargo
add150cb04
chore(deps): update rust crate gix to 0.62.0 [security] [](https://renovatebot.com) This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [gix](https://togithub.com/Byron/gitoxide) | workspace.dependencies | minor | `0.61.0` -> `0.62.0` | ### GitHub Vulnerability Alerts #### [GHSA-98p4-xjmm-8mfh](https://togithub.com/Byron/gitoxide/security/advisories/GHSA-98p4-xjmm-8mfh) ### 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](https://togithub.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 `ssh`. ### PoC To reproduce the known case that facilitates arbitrary code execution, first create a file in the current directory named `configfile@example.com`, of the form ```text 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 `configfile@example.com` as well.) Then run: ```sh gix clone 'ssh://-Fconfigfile@example.com/abc' ``` Or: ```sh gix clone -- '-Fconfigfile@example.com: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 `configfile@example.com` 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 `errors@example.com`, or to create or append to its target if it is a symlink: ```sh gix clone 'ssh://-Eerrors@example.com/abc' ``` ```sh gix clone -- '-Eerrors@example.com:abc/def' ``` ### Impact As in https://github.com/advisories/GHSA-rrjw-j4m2-mf34, 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: - On repositories with submodules that are automatically added, depending how the application manages submodules. - When operating on other repositories from inside an untrusted repository. - When reviewing contributions from untrusted developers by checking out a branch from an untrusted fork and performing clones from that location. --- ### Release Notes <details> <summary>Byron/gitoxide (gix)</summary> ### [`v0.62.0`](https://togithub.com/Byron/gitoxide/releases/tag/gix-v0.62.0): gix v0.62 [Compare Source](https://togithub.com/Byron/gitoxide/compare/gix-v0.61.1...gix-v0.62.0) Please note that this release contains a security fix originally implemented in `gix-transport` via [this PR](https://togithub.com/Byron/gitoxide/pull/1342) which prevents `ssh` options to be smuggled into the `ssh` command-line invocation with a username provided to a clone or fetch URL. Details can be found [in the advisory](https://togithub.com/Byron/gitoxide/security/advisories/GHSA-98p4-xjmm-8mfh). ##### Bug Fixes - `into_index_worktree_iter()` now takes an iterator, instead of a Vec. This makes the API more consistent, and one can pass `None` as well. - show submodules in status independently of their active state. Even inactive submodules are shown in the status by `git status`, so `gix` should do the same. First observed in [https://github.com/helix-editor/helix/pull/5645#issuecomment-2016798212](https://togithub.com/helix-editor/helix/pull/5645#issuecomment-2016798212) - forward `curl` rustls feature from `gix-transport` to avoid `curl` in `gix`. This removes the `curl` dependency just for configuring it, and removes a hazard which became evident with reqwest. ##### Bug Fixes (BREAKING) - Make `topo` more similar to `Ancestors`, but also rename `Ancestors` to `Simple` ##### Commit Statistics - 16 commits contributed to the release over the course of 20 calendar days. - 22 days passed between releases. - 4 commits were understood as [conventional](https://www.conventionalcommits.org/). - 1 unique issue was worked on: [https://github.com/Byron/gitoxide/issues/1328](https://togithub.com/Byron/gitoxide/issues/1328) ##### Thanks Clippy [Clippy](https://togithub.com/rust-lang/rust-clippy) helped 1 time to make code idiomatic. ##### Commit Details - **[https://github.com/Byron/gitoxide/issues/1328](https://togithub.com/Byron/gitoxide/issues/1328)** - Forward `curl` rustls feature from `gix-transport` to avoid `curl` in `gix`. ( |
||
|---|---|---|
| .cargo | ||
| .github | ||
| benches | ||
| ci | ||
| crates | ||
| credential | ||
| src | ||
| tests | ||
| .gitignore | ||
| .ignore | ||
| CHANGELOG.md | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| Cargo.lock | ||
| Cargo.toml | ||
| LICENSE-APACHE | ||
| LICENSE-MIT | ||
| LICENSE-THIRD-PARTY | ||
| README.md | ||
| build.rs | ||
| clippy.toml | ||
| deny.toml | ||
| publish.py | ||
| triagebot.toml | ||
| windows.manifest.xml | ||
README.md
Cargo
Cargo downloads your Rust project’s dependencies and compiles your project.
To start using Cargo, learn more at The Cargo Book.
To start developing Cargo itself, read the Cargo Contributor Guide.
Code Status
Code documentation: https://doc.rust-lang.org/nightly/nightly-rustc/cargo/
Installing Cargo
Cargo is distributed by default with Rust, so if you've got rustc installed
locally you probably also have cargo installed locally.
Compiling from Source
Requirements
Cargo requires the following tools and packages to build:
cargoandrustc- A C compiler for your platform
git(to clone this repository)
Other requirements:
The following are optional based on your platform and needs.
-
pkg-config— This is used to help locate system packages, such aslibsslheaders/libraries. This may not be required in all cases, such as using vendored OpenSSL, or on Windows. -
OpenSSL — Only needed on Unix-like systems and only if the
vendored-opensslCargo feature is not used.This requires the development headers, which can be obtained from the
libssl-devpackage on Ubuntu oropenssl-develwith apk or yum or theopensslpackage from Homebrew on macOS.If using the
vendored-opensslCargo feature, then a static copy of OpenSSL will be built from source instead of using the system OpenSSL. This may require additional tools such asperlandmake.On macOS, common installation directories from Homebrew, MacPorts, or pkgsrc will be checked. Otherwise it will fall back to
pkg-config.On Windows, the system-provided Schannel will be used instead.
LibreSSL is also supported.
Optional system libraries:
The build will automatically use vendored versions of the following libraries. However, if they are provided by the system and can be found with pkg-config, then the system libraries will be used instead:
libcurl— Used for network transfers.libgit2— Used for fetching git dependencies.libssh2— Used for SSH access to git repositories.libz(aka zlib) — Used for data compression.
It is recommended to use the vendored versions as they are the versions that are tested to work with Cargo.
Compiling
First, you'll want to check out this repository
git clone https://github.com/rust-lang/cargo.git
cd cargo
With cargo already installed, you can simply run:
cargo build --release
Adding new subcommands to Cargo
Cargo is designed to be extensible with new subcommands without having to modify Cargo itself. See the Wiki page for more details and a list of known community-developed subcommands.
Releases
Cargo releases coincide with Rust releases. High level release notes are available as part of Rust's release notes. Detailed release notes are available in this repo at CHANGELOG.md.
Reporting issues
Found a bug? We'd love to know about it!
Please report all issues on the GitHub issue tracker.
Contributing
See the Cargo Contributor Guide for a complete introduction to contributing to Cargo.
License
Cargo is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0).
See LICENSE-APACHE and LICENSE-MIT for details.
Third party software
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (https://www.openssl.org/).
In binary form, this product includes software that is licensed under the terms of the GNU General Public License, version 2, with a linking exception, which can be obtained from the upstream repository.
See LICENSE-THIRD-PARTY for details.