Latest security news
Sat, October 24Yesterday
Wasmtime: Panic lowering a host-created component model stream into a guest that expects a different payload type
影響: rust:wasmtime >= 46.0.0, < 48.0.7 → 48.0.7, rust:wasmtime >= 49.0.0, < 49.0.4 → 49.0.4 Wasmtime may panic when the host lowers a component model stream or future into a guest, if the host created that stream or future with one payload type and the guest expects a different one. This can happen when an embedder creates a stream or future, passes it through a guest, receives it back under a type-erased type such as StreamAny or FutureAny, and then passes it to a guest function with a different payload type. GHSA-63h4-6cx9-pjfj is a related advisory also fixing issues within this ar…
Wasmtime: Bit-packing in Cranelift compiler causes silent overflow and miscompilation
影響: rust:wasmtime < 36.0.19 → 36.0.19, rust:wasmtime >= 37.0.0, < 43.0.0 → 43.0.0 In Wasmtime prior to v43, the Cranelift compiler backend bit-packs its SSA value indices in a way that can result in silent overflow in release builds, and result in incorrect value references in the IR resulting in arbitrary miscompilation. A very large Wasm function body, or one that is specially crafted to use many SSA values, can use this to force type-confusion or other arbitrary side-effects and escape the sandbox. Cranelift was changed in Wasmtime v43 to use a full u32 index, with checks…
Tokio: Race condition in `tokio::time::Interval`
影響: rust:tokio = 1.54.0 → 1.54.1 On the multi-threaded runtime, there is a race condition between Interval::poll_tick and the runtime's time driver. This affects Interval only. Sleep and Timeout are not affected. Details In Tokio v1.54.0, a race condition between tokio::time::Interval::poll_tick (including .tick().await) and the runtime time driver can drop an internal timer entry without synchronizing with the driver thread that is firing it. This causes a data race and use-after-free on the timer's waker and task state in sa…
gitoxide gix: untrusted .git/config disables filesystem .git-protection path checks via unfiltered protect_options()
影響: rust:gix >= 0.88.0, <= 0.89.0 → 0.90.0 In the gix crate, Cache::protect_options() in gix/src/config/cache/access.rs reads the three filesystem path-protection settings (core.protectHFS, core.protectNTFS, and gitoxide.core.protectWindows) with the unfiltered gix_config::File::boolean() accessor instead of the trust-aware boolean_filter() accessor used by every other security-critical config read in the same file. When a repository is opened with reduced trust (an ownership mismatch, which maps .git/config sections to Trust::Reduced),…
Fri, October 23
Librsvg: Use-after-free when XML includes have duplicated entities
影響: rust:librsvg < 2.57.5 → 2.57.5, rust:librsvg >= 2.60.0-beta.0, < 2.60.3 → 2.60.3, rust:librsvg >= 2.61.0, < 2.61.5 → 2.61.5, rust:librsvg >= 2.62.0-beta.0, < 2.62.4 → 2.62.4, rust:librsvg >= 2.63.0-beta.0, < 2.63.2 → 2.63.2 Librsvg uses libxml2, a C library, to parse XML. When librsvg parses an SVG document which has a nested Xinclude, an XML entity declaration with a duplicate name as an existing one can cause a use-after-free error. While libxml2 is expanding an internal entity, a recursive XInclude can parse another document that declares an entity with the same name. Both parses use the same XmlState entity map on the librsvg side. entity_insert() replaces the first entry, whose Drop implementation calls xmlFr…
Thu, October 22
ammonia: mXSS via MathML `annotation-xml` encoding strip
影響: rust:ammonia < 3.3.2 → 3.3.2, rust:ammonia >= 4.0.0, < 4.0.2 → 4.0.2, rust:ammonia >= 4.1.0, < 4.1.3 → 4.1.3 If a certain set of MathML tags are enabled, an attacker can inject arbitrary JavaScript code into the user's browser. The annotation-xml tag has slightly different behavior than the other "integration point" tags in MathML and SVG, but ammonia didn't handle it, so it didn't correctly strip the namespace-incompatible tags. This vulnerability only has an effect when the math and annotation-xml tags are both enabled, but the encoding attribute is disabled, because it relies on the following seque…
Slack Morphism verifier errors disclose valid HMACs in the logs
影響: rust:slack-morphism >= 1.0.0, <= 2.27.0 → 2.28.0 Slack Morphism exposes the correct Slack request HMAC when signature verification fails. For an invalid request, slack-morphism computes the correct signature for the attacker-controlled timestamp and request body and stores it in SlackEventWrongSignatureError.generated_hash. The error's Debug and Display representations expose that value, and the default Axum listener error handler logs it at error level. An attacker who can both reach the application's Slack callback endpoint and read…
Tue, October 20
russh: Unbounded memory allocation in agent protocol server via crafted constraint records
影響: rust:russh <= 0.64.0 → 0.64.1 russh_keys::agent::server::add_key (russh/src/keys/agent/server.rs:271-319) spawns a dedicated tokio task for every 5-byte SSH_AGENT_CONSTRAIN_LIFETIME record attached to an added key, each cloning the key blob and sleeping for the declared lifetime (up to ~136 years). The loop has no per-request task budget, and spawned tasks are not rolled back when the overall request fails. Repeating one constrained add-key message over an agent connection converts wire bytes into resident tasks and…
Sat, October 17
Wasmtime: WASI hard links bypass wasmtime-wasi's FilePerms for destination
影響: rust:wasmtime-wasi < 24.0.11 → 24.0.11, rust:wasmtime-wasi >= 25.0.0, < 36.0.12 → 36.0.12, rust:wasmtime-wasi >= 37.0.0, < 45.0.3 → 45.0.3, rust:wasmtime-wasi >= 46.0.0, < 46.0.1 → 46.0.1 Wasmtime's WASI filesystem implementation lets a guest with a read-only source file capability overwrite that file by hard-linking it into another preopen that allows file writes. An attacker who can run a WASI guest can bypass WasiCtxBuilder per-preopen FilePerms and modify host files that were exposed as FilePerms::READ. This attack is possible through the wasip1, wasip2, and wasip3 interfaces to the WASI filesystem. This attack is also possible through an indirection of renaming a ha…
lopdf has a stack overflow via deeply nested PDF objects
影響: rust:lopdf < 0.42.0 → 0.42.0 lopdf::Document::load_mem (and the other load entry points) parses nested PDF arrays and dictionaries with unbounded recursion. A small crafted PDF whose Catalog contains a deeply nested array (/X [[[ … ]]], on the order of 10,000 levels) exhausts the call stack and aborts the process with SIGABRT. Because this is a stack-overflow abort rather than a panic!, it cannot be caught with catch_unwind: any service that parses untrusted PDF input with lopdf can be crashed by a ~21 KB file, resulting i…