CVE-2022-31394 in dependency Hyper(cargo)

[philipjonsen]

Allocation of Resources Without Limits or Throttling

The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.

NVD
Hyperium Hyper before 0.14.19 does not allow for customization of the max_header_list_size method in the H2 third-party software, allowing attackers to perform HTTP2 attacks.

Introduced through
utils/staking-miner/Cargo.lock

FIX:

Update Hyper(Cargo)

hyper
0.14.18

Secure Version
0.14.19

[philipjonsen]

https://nvd.nist.gov/vuln/detail/CVE-2022-31394

[ggwpez]

Why is there even a second Cargo.lock file? I think we can just delete it since it should use the workspace Cargo.lock.

[philipjonsen]

Tokio reject_remote_clients configuration may get dropped when creating a Windows named pipe ### Impact When configuring a Windows named pipe server, setting pipe_mode will reset reject_remote_clients to false. If the application has previously configured reject_remote_clients to true, this effectively undoes the configuration. This also applies if reject_remote_clients is not explicitly set as this is the default configuration and is cleared by calling pipe_mode. Remote clients may only access the named pipe if the named pipe's associated path is accessible via a publically shared folder (SMB). ### Patches The following versions have been patched: * 1.23.1 * 1.20.3 * 1.18.4 The fix will also be present in all releases starting from version 1.24.0. Named pipes were introduced to Tokio in version 1.7.0, so releases older than 1.7.0 are not affected. ### Workarounds Ensure that pipe_mode is set first after initializing a ServerOptions. For example: rust let mut opts = ServerOptions::new(); opts.pipe_mode(PipeMode::Message); opts.reject_remote_clients(true); ### References https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createnamedpipea#pipe_reject_remote_clients

Also in the unused cargo.lock vuln medium (5.3) also

In Rust time crate from version 0.2.7 and before version 0.2.23, unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires the user to set any environment variable in a different thread than the affected functions. The affected functions are time::UtcOffset::local_offset_at, time::UtcOffset::try_local_offset_at, time::UtcOffset::current_local_offset, time::UtcOffset::try_current_local_offset, time::OffsetDateTime::now_local and time::OffsetDateTime::try_now_local. Non-Unix targets are unaffected. This includes Windows and wasm. The issue was introduced in version 0.2.7 and fixed in version 0.2.23.

CVE-2020-26235

and

CVE-2023-22466

[philipjonsen]

This is from the regular cargo, no CVE

bumpalo has use-after-free due to a lifetime error in Vec::into_iter() In affected versions of this crate, the lifetime of the iterator produced by Vec::into_iter() is not constrained to the lifetime of the Bump that allocated the vector's memory. Using the iterator after the Bump is dropped causes use-after-free accesses. The following example demonstrates memory corruption arising from a misuse of this unsoundness. rust use bumpalo::{collections::Vec, Bump}; fn main() { let bump = Bump::new(); let mut vec = Vec::new_in(&bump); vec.extend([0x01u8; 32]); let into_iter = vec.into_iter(); drop(bump); for _ in 0..100 { let reuse_bump = Bump::new(); let _reuse_alloc = reuse_bump.alloc([0x41u8; 10]); } for x in into_iter { print!("0x{:02x} ", x); } println!(); } The issue was corrected in version 3.11.1 by adding a lifetime to the IntoIter type, and updating the signature of Vec::into_iter() to constrain this lifetime.

[philipjonsen]

Update to Secure Version
3.11.1