Rust is a programming language. The Rust Security Response WG was notified that the Rust standard library prior to version 1.77.2 did not properly escape arguments when invoking batch files (with the bat and cmd extensions) on Windows using the Command. An attacker able to control the arguments passed to the spawned process could execute arbitrary shell commands by bypassing the escaping. The severity of this vulnerability is critical for those who invoke batch files on Windows with untrusted arguments. No other platform or use is affected.

The Command::arg and Command::args APIs state in their documentation that the arguments will be passed to the spawned process as-is, regardless of the content of the arguments, and will not be evaluated by a shell. This means it should be safe to pass untrusted input as an argument.

On Windows, the implementation of this is more complex than other platforms, because the Windows API only provides a single string containing all the arguments to the spawned process, and it's up to the spawned process to split them. Most programs use the standard C run-time argv, which in practice results in a mostly consistent way arguments are splitted.

One exception though is cmd.exe (used among other things to execute batch files), which has its own argument splitting logic. That forces the standard library to implement custom escaping for arguments passed to batch files. Unfortunately it was reported that our escaping logic was not thorough enough, and it was possible to pass malicious arguments that would result in arbitrary shell execution.

Due to the complexity of cmd.exe, we didn't identify a solution that would correctly escape arguments in all cases. To maintain our API guarantees, we improved the robustness of the escaping code, and changed the Command API to return an InvalidInput error when it cannot safely escape an argument. This error will be emitted when spawning the process.

The fix is included in Rust 1.77.2. Note that the new escaping logic for batch files errs on the conservative side, and could reject valid arguments. Those who implement the escaping themselves or only handle trusted inputs on Windows can also use the CommandExt::rawarg method to bypass the standard library's escaping logic.

The processlock crate 0.1.0 for Rust allows data races in unlock.

In groupnumber in the scsir crate 0.2.0 for Rust, there can be an overflow because a hardware device may expect a small number of bits (e.g., 5 bits) for group number.

In the anode crate 0.1.0 for Rust, data races can occur in unlock in SpinLock.

Issue 1: Failure to quote characters

Affected versions of this crate allowed the bytes { and \xa0 to appear unquoted and unescaped in command arguments.

If the output of quote or join is passed to a shell, then what should be a single command argument could be interpreted as multiple arguments.

This does not directly allow arbitrary command execution (you can't inject a command substitution or similar). But depending on the command you're running, being able to inject multiple arguments where only one is expected could lead to undesired consequences, potentially including arbitrary command execution.

The flaw was corrected in version 1.2.1 by escaping additional characters. Updating to 1.3.0 is recommended, but 1.2.1 offers a more minimal fix if desired.

Workaround: Check for the bytes { and \xa0 in quote/join input or output.

(Note: { is problematic because it is used for glob expansion. \xa0 is problematic because it's treated as a word separator in [specific environments][solved-xa0].)

Issue 2: Dangerous API w.r.t. nul bytes

Version 1.3.0 deprecates the quote and join APIs in favor of tryquote and tryjoin, which behave the same except that they have Result return type, returning Err if the input contains nul bytes.

Strings containing nul bytes generally cannot be used in Unix command arguments or environment variables, and most shells cannot handle nul bytes even internally. If you try to pass one anyway, then the results might be security-sensitive in uncommon scenarios. [More details here.][nul-bytes]

Due to the low severity, the behavior of the original quote and join APIs has not changed; they continue to allow nuls.

Workaround: Manually check for nul bytes in quote/join input or output.

Issue 3: Lack of documentation for interactive shell risks

The quote family of functions does not and cannot escape control characters. With non-interactive shells this is perfectly safe, as control characters have no special effect. But if you writing directly to the standard input of an interactive shell (or through a pty), then control characters [can cause misbehavior including arbitrary command injection.][control-characters]

This is essentially unfixable, and has not been patched. But as of version 1.3.0, documentation has been added.

Future versions of shlex may add API variants that avoid the issue at the cost of reduced portability.

[solved-xa0]: https://docs.rs/shlex/latest/shlex/quotingwarning/index.html#solved-xa0 [nul-bytes]: https://docs.rs/shlex/latest/shlex/quotingwarning/index.html#nul-bytes [control-characters]: https://docs.rs/shlex/latest/shlex/quotingwarning/index.html#control-characters-interactive-contexts-only

The arrayref crate 0.3.10 for Rust can trigger execution of malicious code when compiling a project that uses the crate, because it has a rogue dependency that registers with a command-and-control server to offer arbitrary code execution.

In the memorypages crate 0.1.0 for Rust, division by zero can occur.

An issue was discovered in rust-ffmpeg 0.3.0 (after comit 5ac0527) A use-after-free vulnerability in the writeinterleaved method allows an attacker to cause a denial of service or memory corruption. The method violates Rust's aliasing rules by modifying a data structure through a mutable pointer while only holding an immutable reference, which can lead to undefined behavior when the data is accessed later.

An issue was discovered in rust-ffmpeg 0.3.0 (after comit 5ac0527) An integer overflow vulnerability in the Vector::new constructor function allows an attacker to cause a denial of service via a null pointer dereference. The vulnerability stems from an unchecked cast of a usize parameter to cint, which can result in a negative value being passed to the underlying C function swsallocVec().

An issue was discovered in rust-ffmpeg 0.3.0 (after comit 5ac0527) Integer overflow and invalid input vulnerability in the cached method allows an attacker to cause a denial of service or potentially execute arbitrary code. The vulnerability occurs when dimension parameters are zero or exceed i32::MAX, leading to an unchecked cast that violates the underlying C function's preconditions and triggers undefined behavior.

An issue was discovered in rust-ffmpeg 0.3.0 (after comit 5ac0527) Null pointer dereference vulnerability in the name() method allows an attacker to cause a denial of service. The vulnerability exists because the method fails to check for a NULL return value from the avgetsamplefmtname() C function, which can be triggered by providing an unrecognized sample format.

A flaw was found in the user's crate for Rust. This vulnerability allows privilege escalation via incorrect group listing when a user or process has fewer than exactly 1024 groups, leading to the erroneous inclusion of the root group in the access list.

Affected versions append root to group listings, unless the correct listing has exactly 1024 groups.

This affects both:

- The supplementary groups of a user - The group access list of the current process

If the caller uses this information for access control, this may lead to privilege escalation.

This crate is not currently maintained, so a patched version is not available.

Versions older than 0.8.0 do not contain the affected functions, so downgrading to them is a workaround.

Recommended alternatives - uzers (an actively maintained fork of the users crate) - sysinfo

Cargo incorrectly handled symlinks inside of crate tarballs downloaded from third-party registries, allowing a malicious crate to override the source code of another crate from the same registry. The severity of the vulnerability is medium for users of third-party registries. Users of crates.io are not affected, as crates.io forbids uploading crates containing any symlink.

Starting from Rust 1.87.0 and before Rust 1.89.0, the tier 3 Cygwin target (x8664-pc-cygwin) didn't correctly handle path separators, causing the standard library's Path API to ignore path components separated by backslashes. Due to this, programs compiled for Cygwin that validate paths could misbehave, potentially allowing path traversal attacks or malicious filesystem operations.

Rust 1.89.0 fixes the issue by handling both Win32 and Unix style paths in the standard library for the Cygwin target.

While we assess the severity of this vulnerability as "medium", please note that the tier 3 Cygwin compilation target is only available when building it from source: no pre-built binaries are distributed by the Rust project, and it cannot be installed through Rustup. Unless you manually compiled the x8664-pc-cygwin target you are not affected by this vulnerability. Users of the tier 1 MinGW target (x8664-pc-windows-gnu) are also explicitly not affected.

The ed25519-dalek crate before 2 for Rust allows a double public key signing function oracle attack. The Keypair implementation leads to a simple computation for extracting a private key.

ring::aead::quic::HeaderProtectionKey::newmask() may panic when overflow checking is enabled. In the QUIC protocol, an attacker can induce this panic by sending a specially-crafted packet. Even unintentionally it is likely to occur in 1 out of every 232 packets sent and/or received.

On 64-bit targets operations using ring::aead::{AES128GCM, AES256GCM} may panic when overflow checking is enabled, when encrypting/decrypting approximately 68,719,476,700 bytes (about 64 gigabytes) of data in a single chunk. Protocols like TLS and SSH are not affected by this because those protocols break large amounts of data into small chunks. Similarly, most applications will not attempt to encrypt/decrypt 64GB of data in one chunk.

Overflow checking is not enabled in release mode by default, but RUSTFLAGS="-C overflow-checks" or overflow-checks = true in the Cargo.toml profile can override this. Overflow checking is usually enabled by default in debug mode.

Given the function transpose::transpose: rust fn transpose<T: Copy>(input: &[T], output: &mut [T], inputwidth: usize, inputheight: usize)

The safety check inputwidth inputheight == output.len() can fail due to inputwidth inputheight overflowing in such a way that it equals output.len(). As a result of failing the safety check, memory past the end of output is written to. This only occurs in release mode since panics on overflow in debug mode.

Exploiting this issue requires the caller to pass inputwidth and inputheight arguments such that multiplying them overflows, and the overflown result equals the lengths of input and output slices.

Affected versions of the crate have several bugs where attacker-controlled input can result in the use of an out-of-bound array index. Rust detects the use of the out-of-bound index and causes the application to panic. An attacker may be able to use this to cause a denial-of-service. However, it is not possible for an attacker to read from or write to the application's address space.

Affected versions of the crate have a bug where attacker-controlled input can result in the use of an out-of-bound array index. Rust detects the use of the out-of-bound index and causes the application to panic. An attacker may be able to use this to cause a denial-of-service. However, it is not possible for an attacker to read from or write to the application's address space.

An issue was discovered in rust-ffmpeg 0.3.0 (after comit 5ac0527) Null pointer dereference vulnerability in the dump() method allows an attacker to cause a denial of service. The vulnerability exists because the method fails to check the return value of avfiltergraphdump() for NULL, leading to a crash if the underlying memory allocation fails.

Impact There was a logic bug where unauthenticated payloads could still cause a nonce increment in snow's internal state. For an attacker with the ability to inject packets into the channel Noise is talking over, this allows a denial-of-service type attack which could prevent communication as it causes the sending and receiving side to be expecting different nonce values than would arrive.

Note that this only affects those who are using the stateful TransportState, not those using StatelessTransportState.

Patches This has been patched in version 0.9.5, and all users are recommended to update.

References There will be a more formal report of this in the near future.

The 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 this issue.

Description: A timing based side-channel exists in the rust-openssl package which could be sufficient to recover a plaintext across a network in a Bleichenbacher style attack. To achieve successful decryption an attacker would have to be able to send a large number of trial messages for decryption. The vulnerability affects the legacy PKCS#1v1.5 RSA encryption padding mode.

References: https://people.redhat.com/~hkario/marvin/ https://github.com/sfackler/rust-openssl/issues/2171

The web-push crate before 0.10.3 for Rust allows a denial of service (memory consumption) in the built-in clients via a large integer in a Content-Length header.

The Tungstenite crate through 0.20.0 for Rust allows remote attackers to cause a denial of service (minutes of CPU consumption) via an excessive length of an HTTP header in a client handshake. The length affects both how many times a parse is attempted (e.g., thousands of times) and the average amount of data for each parse attempt (e.g., millions of bytes).

Cargo between 1.68 and 1.96 incorrectly normalized the URLs of third-party registries using the sparse index protocol. If a hosting provider allowed multiple registries to be hosted with arbitrary names within the same domain, an attacker able to publish crates in a registry could obtain the credentials of others users of the same registry. The severity of the vulnerability is low, due to the extremely niche requirements needed to achieve the attack.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

The Rust Security Response WG was notified that Cargo did not respect the umask when extracting crate archives on UNIX-like systems. If the user downloaded a crate containing files writeable by any local user, another local user could exploit this to change the source code compiled and executed by the current user.

This vulnerability has been assigned CVE-2023-38497.

Overview

In UNIX-like systems, each file has three sets of permissions: for the user owning the file, for the group owning the file, and for all other local users. The "[umask][1]" is configured on most systems to limit those permissions during file creation, removing dangerous ones. For example, the default umask on macOS and most Linux distributions only allow the user owning a file to write to it, preventing the group owning it or other local users from doing the same.

When a dependency is downloaded by Cargo, its source code has to be extracted on disk to allow the Rust compiler to read as part of the build. To improve performance, this extraction only happens the first time a dependency is used, caching the pre-extracted files for future invocations.

Unfortunately, it was discovered that Cargo did not respect the umask during extraction, and propagated the permissions stored in the crate archive as-is. If an archive contained files writeable by any user on the system (and the system configuration didn't prevent writes through other security measures), another local user on the system could replace or tweak the source code of a dependency, potentially achieving code execution the next time the project is compiled.

Affected Versions

All Rust versions before 1.71.1 on UNIX-like systems (like macOS and Linux) are affected. Note that additional system-dependent security measures configured on the local system might prevent the vulnerability from being exploited.

Users on Windows and other non-UNIX-like systems are not affected.

Mitigations

We recommend all users to update to Rust 1.71.1, which will be released later today, as it fixes the vulnerability by respecting the umask when extracting crate archives. If you build your own toolchain, patches for 1.71.0 source tarballs are [available here][2].

To prevent existing cached extractions from being exploitable, the Cargo binary included in Rust 1.71.1 or later will purge the caches it tries to access if they were generated by older Cargo versions.

If you cannot update to Rust 1.71.1, we recommend configuring your system to prevent other local users from accessing the Cargo directory, usually located in ~/.cargo:

chmod go= ~/.cargo

Acknowledgments

We want to thank Addison Crump for responsibly disclosing this to us according to the [Rust security policy][3].

We also want to thank the members of the Rust project who helped us disclose the vulnerability: Weihang Lo for developing the fix; Eric Huss for reviewing the fix; Pietro Albini for writing this advisory; Pietro Albini, Manish Goregaokar and Josh Stone for coordinating this disclosure; Josh Triplett, Arlo Siemen, Scott Schafer, and Jacob Finkelman for advising during the disclosure.

[1]: https://en.wikipedia.org/wiki/Umask [2]: https://github.com/rust-lang/wg-security-response/tree/main/patches/CVE-2023-38497 [3]: https://www.rust-lang.org/policies/security -----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEV2nIi/XdPRSiNKes77mGCudSDawFAmTLX38ACgkQ77mGCudS Daxn7Q/+Oid260WnVd1sH9njTJt/+zBImTjbfNaMge6PzFteKat/D15YPgpaFEmy WM+gH9ejz+oOgjw2DTdeMHzh9i137kchNfzgEY6Cl0SMxc5NymA47Q2zrSt+TBK6 L362q5dw/Ic1Sf5GRt7J4xeLjY4Vj8FFve1Jnd3VW+QQkATBJn01SLyTD4uXE5tJ 1UX9IkG1n2y9wXgvkmMYInAnOux8mAb5Sx5JYAtPBO7jV2xfg5ffME6BIzH4F7xw wL5k7epvHbtwt2eHVetbHf8UjTiuZxDK8GWbMPqe59AheoLRfgmw06qxVwxI8lEJ cWTnZDZEdSXgpy9OphoTYAonQp7qdzoQdXpc4dQxpWkTa3+kvB9SD9H+OVTiYYEv EctRt7CQGeTFmpotwq3wwpv8XjWvpjdRie1TIMA5WejZecHiL/iiZxkn00DxW3RP dp6Qvqb/jxl7dfRTSm3mH+iqVkv8GtEWwbfK0LE3i9O1ezmQ0m7kjKbgv+NP8p8v mtGM1K/IDGYIUgOXha46wqXv9/1f6tCeOcuC9C1j24Jbl7ScmwanQ0VmZWZBfhFD EBrLaSlHl45GwSyEaIe7REtOrCR4UCAvHMe1Rxw0KdWe//8Qrtq4agqVg4DYr0/h WzDXqlbVAQqKWehaQtJfhQ8xW3XYQBmYLZOsWmBKUKVMnUsTkFQ= =XCFS -----END PGP SIGNATURE-----

End of life: 7/4/2019, Latest version: 1.35.0