CVE Vulnerabilities

CVE-2022-39392

Out-of-bounds Read

Published: Nov 10, 2022 | Modified: Jun 27, 2023
CVSS 3.x
7.4
HIGH
Source:
NVD
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
CVSS 2.x
RedHat/V2
RedHat/V3
Ubuntu
MEDIUM

Wasmtime is a standalone runtime for WebAssembly. Prior to version 2.0.2, there is a bug in Wasmtimes implementation of its pooling instance allocator when the allocator is configured to give WebAssembly instances a maximum of zero pages of memory. In this configuration, the virtual memory mapping for WebAssembly memories did not meet the compiler-required configuration requirements for safely executing WebAssembly modules. Wasmtimes default settings require virtual memory page faults to indicate that wasm reads/writes are out-of-bounds, but the pooling allocators configuration would not create an appropriate virtual memory mapping for this meaning out of bounds reads/writes can successfully read/write memory unrelated to the wasm sandbox within range of the base address of the memory mapping created by the pooling allocator. This bug is not applicable with the default settings of the wasmtime crate. This bug can only be triggered by setting InstanceLimits::memory_pages to zero. This is expected to be a very rare configuration since this means that wasm modules cannot allocate any pages of linear memory. All wasm modules produced by all current toolchains are highly likely to use linear memory, so its expected to be unlikely that this configuration is set to zero by any production embedding of Wasmtime. This bug has been patched and users should upgrade to Wasmtime 2.0.2. This bug can be worked around by increasing the memory_pages allotment when configuring the pooling allocator to a value greater than zero. If an embedding wishes to still prevent memory from actually being used then the Store::limiter method can be used to dynamically disallow growth of memory beyond 0 bytes large. Note that the default memory_pages value is greater than zero.

Weakness

The product reads data past the end, or before the beginning, of the intended buffer.

Affected Software

Name Vendor Start Version End Version
Wasmtime Bytecodealliance * 1.0.2 (excluding)
Wasmtime Bytecodealliance 2.0.0 (including) 2.0.2 (excluding)
Firefox Ubuntu bionic *
Firefox Ubuntu focal *
Firefox Ubuntu trusty *
Firefox Ubuntu xenial *
Mozjs38 Ubuntu bionic *
Mozjs38 Ubuntu esm-apps/bionic *
Mozjs38 Ubuntu upstream *
Mozjs52 Ubuntu bionic *
Mozjs52 Ubuntu esm-apps/focal *
Mozjs52 Ubuntu esm-infra/bionic *
Mozjs52 Ubuntu focal *
Mozjs52 Ubuntu upstream *
Mozjs68 Ubuntu focal *
Mozjs68 Ubuntu upstream *
Mozjs78 Ubuntu esm-apps/jammy *
Mozjs78 Ubuntu jammy *
Mozjs78 Ubuntu kinetic *
Mozjs78 Ubuntu lunar *
Mozjs78 Ubuntu upstream *
Mozjs91 Ubuntu jammy *
Mozjs91 Ubuntu upstream *
Thunderbird Ubuntu bionic *
Thunderbird Ubuntu devel *
Thunderbird Ubuntu focal *
Thunderbird Ubuntu jammy *
Thunderbird Ubuntu kinetic *
Thunderbird Ubuntu lunar *
Thunderbird Ubuntu mantic *
Thunderbird Ubuntu noble *
Thunderbird Ubuntu trusty *
Thunderbird Ubuntu xenial *

Potential Mitigations

  • Assume all input is malicious. Use an “accept known good” input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, “boat” may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as “red” or “blue.”
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code’s environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • To reduce the likelihood of introducing an out-of-bounds read, ensure that you validate and ensure correct calculations for any length argument, buffer size calculation, or offset. Be especially careful of relying on a sentinel (i.e. special character such as NUL) in untrusted inputs.

References