CVE-2023-40030

Cargo downloads a Rust project’s dependencies and compiles the project. Starting in Rust 1.60.0 and prior to 1.72, Cargo did not escape Cargo feature names when including them in the report generated by cargo build --timings. A malicious package included as a dependency may inject nearly arbitrary HTML here, potentially leading to cross-site scripting if the report is subsequently uploaded somewhere. The vulnerability affects users relying on dependencies from git, local paths, or alternative registries. Users who solely depend on crates.io are unaffected.

Rust 1.60.0 introduced cargo build --timings, which produces a report of how long the different steps of the build process took. It includes lists of Cargo features for each crate. Prior to Rust 1.72, Cargo feature names were allowed to contain almost any characters (with some exceptions as used by the feature syntax), but it would produce a future incompatibility warning about them since Rust 1.49. crates.io is far more stringent about what it considers a valid feature name and has not allowed such feature names. As the feature names were included unescaped in the timings report, they could be used to inject Javascript into the page, for example with a feature name like features = ["<img src='' onerror=alert(0)"]. If this report were subsequently uploaded to a domain that uses credentials, the injected Javascript could access resources from the website visitor.

This issue was fixed in Rust 1.72 by turning the future incompatibility warning into an error. Users should still exercise care in which package they download, by only including trusted dependencies in their projects. Please note that even with these vulnerabilities fixed, by design Cargo allows arbitrary code execution at build time thanks to build scripts and procedural macros: a malicious dependency will be able to cause damage regardless of these vulnerabilities. crates.io has server-side checks preventing this attack, and there are no packages on crates.io exploiting these vulnerabilities. crates.io users still need to excercise care in choosing their dependencies though, as remote code execution is allowed by design there as well.

Cargo downloads a Rust project’s dependencies and compiles the project. Starting in Rust 1.60.0 and prior to 1.72, Cargo did not escape Cargo feature names when including them in the report generated by cargo build --timings. A malicious package included as a dependency may inject nearly arbitrary HTML here, potentially leading to cross-site scripting if the report is subsequently uploaded somewhere. The vulnerability affects users relying on dependencies from git, local paths, or alternative registries. Users who solely depend on crates.io are unaffected. Rust 1.60.0 introduced cargo build --timings, which produces a report of how long the different steps of the build process took. It includes lists of Cargo features for each crate. Prior to Rust 1.72, Cargo feature names were allowed to contain almost any characters (with some exceptions as used by the feature syntax), but it would produce a future incompatibility warning about them since Rust 1.49. crates.io is far more stringent about what it considers a valid feature name and has not allowed such feature names. As the feature names were included unescaped in the timings report, they could be used to inject Javascript into the page, for example with a feature name like features = ["<img src='' onerror=alert(0)"]. If this report were subsequently uploaded to a domain that uses credentials, the injected Javascript could access resources from the website visitor. This issue was fixed in Rust 1.72 by turning the future incompatibility warning into an error. Users should still exercise care in which package they download, by only including trusted dependencies in their projects. Please note that even with these vulnerabilities fixed, by design Cargo allows arbitrary code execution at build time thanks to build scripts and procedural macros: a malicious dependency will be able to cause damage regardless of these vulnerabilities. crates.io has server-side checks preventing this attack, and there are no packages on crates.io exploiting these vulnerabilities. crates.io users still need to excercise care in choosing their dependencies though, as remote code execution is allowed by design there as well.

Cargo downloads a Rust project’s dependencies and compiles the project. Starting in Rust 1.60.0 and prior to 1.72, Cargo did not escape Cargo feature names when including them in the report generated by cargo build --timings. A malicious package included as a dependency may inject nearly arbitrary HTML here, potentially leading to cross-site scripting if the report is subsequently uploaded somewhere. The vulnerability affects users relying on dependencies from git, local paths, or alternative registries. Users who solely depend on crates.io are unaffected. Rust 1.60.0 introduced cargo build --timings, which produces a report of how long the different steps of the build process took. It includes lists of Cargo features for each crate. Prior to Rust 1.72, Cargo feature names were allowed to contain almost any characters (with some exceptions as used by the feature syntax), but it would produce a future incompatibility warning about them since Rust 1.49. crates.io is far more stringent about what it considers a valid feature name and has not allowed such feature names. As the feature names were included unescaped in the timings report, they could be used to inject Javascript into the page, for example with a feature name like features = ["<img src='' onerror=alert(0)"]. If this report were subsequently uploaded to a domain that uses credentials, the injected Javascript could access resources from the website visitor. This issue was fixed in Rust 1.72 by turning the future incompatibility warning into an error. Users should still exercise care in which package they download, by only including trusted dependencies in their projects. Please note that even with these vulnerabilities fixed, by design Cargo allows arbitrary code execution at build time thanks to build scripts and procedural macros: a malicious dependency will be able to cause damage regardless of these vulnerabilities. crates.io has server-side checks preventing this attack, and there are no packages on crates.io exploiting these vulnerabilities. crates.io users still need to excercise care in choosing their dependencies though, as remote code execution is allowed by design there as well.

The Rust Security Response WG was notified that Cargo did not escape Cargo feature names when including them in the report generated by cargo build --timings. A malicious package included as a dependency may inject nearly arbitrary HTML here, potentially leading to XSS if the report is subsequently uploaded somewhere.

The severity of this vulnerability is "low" for users relying on dependencies from git, local paths, or alternative registries. Users who solely depend on crates.io are unaffected.

Note that by design Cargo allows code execution at build time, due to build scripts and procedural macros. The vulnerability in this advisory allows performing a subset of the possible damage in a harder to track down way. Your dependencies must still be trusted if you want to be protected from attacks, as it's possible to perform the same attacks with build scripts and procedural macros.

Overview

Rust 1.60.0 introduced cargo build --timings, which produces a report of how long the different steps of the build process took. It includes lists of Cargo features for each crate.

Prior to Rust 1.72, Cargo feature names were allowed to contain almost any characters (with some exceptions as used by the feature syntax), but it would produce a future incompatibility warning about them since Rust 1.49. crates.io is far more stringent about what it considers a valid feature name and has not allowed such feature names.

As the feature names defined in the Cargo.toml file were included unescaped in the timings report, they could be used to inject Javascript into the page. For example with a feature name like features = ["<img src='' onerror=alert(0)"]. If this report were subsequently uploaded to a domain that uses credentials, the injected Javascript could access resources from the website visitor.

This issue was fixed by turning the future incompatibility warning into an error.

Affected versions

The vulnerability is present in all versions of Cargo after and including 1.60.0. Rust 1.72, to be released on August 24, will include a fix for it.

Users whose dependencies are entirely on crates.io are unaffected.

Mitigations

We recommend users always excercise care in which package they download, by only including trusted dependencies in their projects. Please note that even with these vulnerabilities fixed, by design Cargo allows arbitrary code execution at build time thanks to build scripts and procedural macros: a malicious dependency will be able to cause damage regardless of these vulnerabilities.

crates.io has server-side checks preventing this attack, and there are no packages on crates.io exploiting these vulnerabilities. crates.io users still need to excercise care in choosing their dependencies though, as remote code execution is allowed by design there as well.

These are all security issues fixed in the cargo1.72-1.72.1-1.1 package on the GA media of openSUSE Tumbleweed.

This update for rust, rust1.72 fixes the following issues:

Changes in rust:

• Update to version 1.72.0 - for details see the rust1.72 package

Changes in rust1.72:

• CVE-2023-40030: fix minor non-exploited issue in cargo (bsc#1214689)

Version 1.72.0 (2023-08-24)

Language

• Replace const eval limit by a lint and add an exponential backoff warning
• expand: Change how #![cfg(FALSE)] behaves on crate root
• Stabilize inline asm for LoongArch64
• Uplift clippy::undropped_manually_drops lint
• Uplift clippy::invalid_utf8_in_unchecked lint
• Uplift clippy::cast_ref_to_mut lint
• Uplift clippy::cmp_nan lint
• resolve: Remove artificial import ambiguity errors
• Don't require associated types with Self: Sized bounds in dyn Trait objects

Compiler

• Remember names of cfg-ed out items to mention them in diagnostics
• Support for native WASM exceptions
• Add support for NetBSD/aarch64-be (big-endian arm64).
• Write to stdout if - is given as output file
• Force all native libraries to be statically linked when linking a static binary
• Add Tier 3 support for loongarch64-unknown-none*
• Prevent .eh_frame from being emitted for -C panic=abort
• Support 128-bit enum variant in debuginfo codegen
• compiler: update solaris/illumos to enable tsan support.

Refer to Rust's platform support page for more information on Rust's tiered platform support.

Libraries

• Document memory orderings of thread::{park, unpark}
• io: soften ‘at most one write attempt’ requirement in io::Write::write
• Specify behavior of HashSet::insert
• Relax implicit T: Sized bounds on BufReader<T>, BufWriter<T> and LineWriter<T>
• Update runtime guarantee for select_nth_unstable
• Return Ok on kill if process has already exited
• Implement PartialOrd for Vecs over different allocators
• Use 128 bits for TypeId hash
• Don't drain-on-drop in DrainFilter impls of various collections.
• Make {Arc,Rc,Weak}::ptr_eq ignore pointer metadata

Rustdoc

• Allow whitespace as path separator like double colon
• Add search result item types after their name
• Search for slices and arrays by type with []
• Clean up type unification and 'unboxing'

Stabilized APIs

• impl<T: Send> Sync for mpsc::Sender<T>
• impl TryFrom<&OsStr> for &str
• String::leak

These APIs are now stable in const contexts:

• CStr::from_bytes_with_nul
• CStr::to_bytes
• CStr::to_bytes_with_nul
• CStr::to_str

Cargo

• Enable -Zdoctest-in-workspace by default. When running each documentation test, the working directory is set to the root directory of the package the test belongs to.
• Add support of the 'default' keyword to reset previously set build.jobs parallelism back to the default.

Compatibility Notes

• Alter Display for Ipv6Addr for IPv4-compatible addresses
• Cargo changed feature name validation check to a hard error. The warning was added in Rust 1.49. These extended characters aren't allowed on crates.io, so this should only impact users of other registries, or people who don't publish to a registry.