ghsa

Version 0.6.0 of the `simple_asn1` crate panics on certain malformed inputs to its parsing functions, including `from_der` and `der_decode`. Because this crate is frequently used with inputs from the network, this should be considered a security vulnerability. The issue occurs when parsing the old ASN.1 "UTCTime" time format. If an attacker provides a UTCTime where the first character is ASCII but the second character is above 0x7f, a string slice operation in the `from_der_` function will try to slice into the middle of a UTF-8 character, and cause a panic. This error was introduced in commit [`d7d39d709577710e9dc8`](https://github.com/acw/simple_asn1/commit/d7d39d709577710e9dc8833ee57d200eef366db8), which updated `simple_asn1` to use `time` instead of `chrono` because of [`RUSTSEC-2020-159`](https://rustsec.org/advisories/RUSTSEC-2020-0159). Versions of `simple_asn1` before 0.6.0 are not affected by this issue. The [patch](https://github.com/acw/simple_asn1/pull/28) was applied i...

The v0.9.7 release of the `sha2` crate introduced a new AVX2-accelerated backend which was automatically enabled for all x86/x86_64 CPUs where AVX2 support was autodetected at runtime. This backend was buggy and would miscompute results for long messages (i.e. messages spanning multiple SHA blocks). The crate has since been yanked, but any users who upgraded to v0.9.7 should immediately upgrade to v0.9.8 and recompute any hashes which were previously computed by v0.9.7.

Affected versions of this crate did not properly calculate secret shares requirements. This reduces the security of the algorithm by restricting the crate to always using a threshold value of three, rather than a configurable limit. The flaw was corrected by correctly configuring the threshold.

When parsing JSON using `json::Json::from_str`, there is no limit to the depth of the stack, therefore deeply nested objects can cause a stack overflow, which aborts the process. Example code that triggers the vulnerability is ```rust fn main() { let _ = rustc_serialize::json::Json::from_str(&"[0,[".repeat(10000)); } ``` [serde](https://crates.io/crates/serde) is recommended as a replacement to rustc_serialize.

When running in debug mode and the `debug-embed` (off by default) feature is not enabled, the generated `get` method does not check that the input path is a child of the folder given. This allows attackers to read arbitrary files in the file system if they have control over the filename given. The following code will print the contents of your `/etc/passwd` if adjusted with a correct number of `../`s depending on where it is run from. ```rust #[derive(rust_embed::RustEmbed)] #[folder = "src/"] pub struct Asset; fn main() { let d = Asset::get("../../../etc/passwd").unwrap().data; println!("{}", String::from_utf8_lossy(&d)); } ``` The flaw was corrected by canonicalizing the input filename and ensuring that it starts with the canonicalized folder path.

The following Rust program demonstrates some strangeness in AES encryption - if you have an immutable key slice and then operate on that slice, you get different encryption output than if you operate on a copy of that key. For these functions, we expect that extending a 16 byte key to a 32 byte key by repeating it gives the same encrypted data, because the underlying rust-crypto functions repeat key data up to the necessary key size for the cipher. ```rust use crypto::{ aes, blockmodes, buffer, buffer::{BufferResult, ReadBuffer, WriteBuffer}, symmetriccipher, }; fn encrypt( key: &[u8], iv: &[u8], data: &str, ) -> Result<String, symmetriccipher::SymmetricCipherError> { let mut encryptor = aes::cbc_encryptor(aes::KeySize::KeySize256, key, iv, blockmodes::PkcsPadding); let mut encrypted_data = Vec::<u8>::new(); let mut read_buffer = buffer::RefReadBuffer::new(data.as_bytes()); let mut buffer = [0; 4096]; let mut write_buffer = buffer...

The lifetime bound on several closure-accepting `rusqlite` functions (specifically, functions which register a callback to be later invoked by SQLite) was too relaxed. If a closure referencing borrowed values on the stack is was passed to one of these functions, it could allow Rust code to access objects on the stack after they have been dropped. The impacted functions are: - Under `cfg(feature = "functions")`: `Connection::create_scalar_function`, `Connection::create_aggregate_function` and `Connection::create_window_function`. - Under `cfg(feature = "hooks")`: `Connection::commit_hook`, `Connection::rollback_hook` and `Connection::update_hook`. - Under `cfg(feature = "collation")`: `Connection::create_collation`. The issue exists in all `0.25.*` versions prior to `0.25.4`, and all `0.26.*` versions prior to 0.26.2 (specifically: `0.25.0`, `0.25.1`, `0.25.2`, `0.25.3`, `0.26.0`, and `0.26.1`). The fix is available in versions `0.26.2` and newer, and also has been back-ported to `0...

When activating the non-default feature `serialize`, most structs implement `serde::Deserialize` without sufficient validation. This allows breaking invariants in safe code, leading to: * Undefined behavior in `as_string()` methods (which use `std::str::from_utf8_unchecked()` internally). * Panics due to failed assertions. See https://github.com/gz/rust-cpuid/issues/43.

This is impossible to do by accident, but by carefully constructing marker types to be covariant, a malicious coder can cheat the singleton check in `TCellOwner` and `TLCellOwner`, giving unsound access to cell memory. This could take the form of getting two mutable references to the same memory, or a mutable reference and an immutable reference. The fix is for the crate to internally force the marker type to be invariant. This blocks the conversion between covariant types which Rust normally allows.

`rdiff` performs a diff of two provided strings or files. As part of its reading code it uses the return value of a `Read` instance to set the length of its internal character vector. If the `Read` implementation claims that it has read more bytes than the length of the provided buffer, the length of the vector will be set to longer than its capacity. This causes `rdiff` APIs to return uninitialized memory in its API methods.