CVSS: 2.3EPSS: 0%CPEs: 1EXPL: 0CVE-2024-51756 – cap-std doesn't fully sandbox all the Windows device filenames
https://notcve.org/view.php?id=CVE-2024-51756
The cap-std project is organized around the eponymous `cap-std` crate, and develops libraries to make it easy to write capability-based code. cap-std's filesystem sandbox implementation on Windows blocks access to special device filenames such as "COM1", "COM2", "LPT0", "LPT1", and so on, however it did not block access to the special device filenames which use superscript digits, such as "COM¹", "COM²", "LPT⁰", "LPT¹", and so on. Untrusted filesystem paths could bypass the sandbox and access devices through those special device filenames with superscript digits, and through them provide access peripheral devices connected to the computer, or network resources mapped to those devices. This can include modems, printers, network printers, and any other device connected to a serial or parallel port, including emulated USB serial ports. The bug is fixed in #371, which is published in cap-primitives 3.4.1, cap-std 3.4.1, and cap-async-std 3.4.1. There are no known workarounds for this issue. • https://en.wikipedia.org/wiki/ISO/IEC_8859-1 https://github.com/bytecodealliance/cap-std/commit/dcc3818039761331fbeacbb3a40c542b65b5ebf7 https://github.com/bytecodealliance/cap-std/pull/371 https://github.com/bytecodealliance/cap-std/security/advisories/GHSA-hxf5-99xg-86hw https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions • CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') •
CVSS: 2.3EPSS: 0%CPEs: 3EXPL: 0CVE-2024-51745 – Wasmtime doesn't fully sandbox all the Windows device filenames
https://notcve.org/view.php?id=CVE-2024-51745
Wasmtime is a fast and secure runtime for WebAssembly. Wasmtime's filesystem sandbox implementation on Windows blocks access to special device filenames such as "COM1", "COM2", "LPT0", "LPT1", and so on, however it did not block access to the special device filenames which use superscript digits, such as "COM¹", "COM²", "LPT⁰", "LPT¹", and so on. Untrusted Wasm programs that are given access to any filesystem directory could bypass the sandbox and access devices through those special device filenames with superscript digits, and through them gain access peripheral devices connected to the computer, or network resources mapped to those devices. This can include modems, printers, network printers, and any other device connected to a serial or parallel port, including emulated USB serial ports. Patch releases for Wasmtime have been issued as 24.0.2, 25.0.3, and 26.0.1. • https://en.wikipedia.org/wiki/ISO/IEC_8859-1 https://github.com/bytecodealliance/cap-std/pull/371 https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-c2f5-jxjv-2hh8 https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions • CWE-67: Improper Handling of Windows Device Names CWE-184: Incomplete List of Disallowed Inputs •
CVSS: 2.9EPSS: 0%CPEs: 5EXPL: 0CVE-2024-47813 – Wasmtime race condition could lead to WebAssembly control-flow integrity and type safety violations
https://notcve.org/view.php?id=CVE-2024-47813
Wasmtime is an open source runtime for WebAssembly. Under certain concurrent event orderings, a `wasmtime::Engine`'s internal type registry was susceptible to double-unregistration bugs due to a race condition, leading to panics and potentially type registry corruption. That registry corruption could, following an additional and particular sequence of concurrent events, lead to violations of WebAssembly's control-flow integrity (CFI) and type safety. Users that do not use `wasmtime::Engine` across multiple threads are not affected. Users that only create new modules across threads over time are additionally not affected. • https://github.com/bytecodealliance/wasmtime/pull/7969 https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-7qmx-3fpx-r45m • CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-47763 – Wasmtime runtime crash when combining tail calls with trapping imports
https://notcve.org/view.php?id=CVE-2024-47763
Wasmtime is an open source runtime for WebAssembly. Wasmtime's implementation of WebAssembly tail calls combined with stack traces can result in a runtime crash in certain WebAssembly modules. The runtime crash may be undefined behavior if Wasmtime was compiled with Rust 1.80 or prior. The runtime crash is a deterministic process abort when Wasmtime is compiled with Rust 1.81 and later. WebAssembly tail calls are a proposal which relatively recently reached stage 4 in the standardization process. • https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_tail_call https://github.com/WebAssembly/proposals https://github.com/bytecodealliance/wasmtime/pull/8540 https://github.com/bytecodealliance/wasmtime/pull/8682 https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-q8hx-mm92-4wvg https://github.com/webassembly/tail-call • CWE-670: Always-Incorrect Control Flow Implementation •
CVSS: 6.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-43806 – `rustix::fs::Dir` iterator with the `linux_raw` backend can cause memory explosion
https://notcve.org/view.php?id=CVE-2024-43806
Rustix is a set of safe Rust bindings to POSIX-ish APIs. When using `rustix::fs::Dir` using the `linux_raw` backend, it's possible for the iterator to "get stuck" when an IO error is encountered. Combined with a memory over-allocation issue in `rustix::fs::Dir::read_more`, this can cause quick and unbounded memory explosion (gigabytes in a few seconds if used on a hot path) and eventually lead to an OOM crash of the application. The symptoms were initially discovered in https://github.com/imsnif/bandwhich/issues/284. That post has lots of details of our investigation. • https://github.com/bytecodealliance/rustix/security/advisories/GHSA-c827-hfw6-qwvm https://github.com/imsnif/bandwhich/issues/284 • CWE-400: Uncontrolled Resource Consumption •