Full Report
The function DefaultReferenceValue() returns undefined as a default value for two different types. According to the wasm-gc specification, only null values can be used for reference types. So, why does this violation of the specification matter? There are invariants in these complicated programs. For instance, only these X amount of types will be seen here or a value in the range of X..Y will be there. These constraints are then used throughout the codebase. So, once one of these invariants in violated, it causes major havoc. The only allowed value for nullexternref is a JS null, but this has been broken. Optimizing compilers are now likely to optimize code incorrectly. Additionally, kNoExtern as undefined may be confused with other types. Using point 2, they were able to craft a string with an invalid length to cause a crash. Neat bug! Reading the specification is helpful when multiple things rely on it.
Analysis Summary
# Vulnerability: Incorrect Default Value Handling in WebAssembly Garbage Collection (Wasm-GC)
## CVE Details
- **CVE ID:** CVE-2024-5491
- **CVSS Score:** 8.8 (High)
- **CWE:** CWE-617: Reachable Assertion; CWE-697: Incorrect Comparison
## Affected Systems
- **Products:** Chromium-based browsers (Google Chrome, Microsoft Edge, Brave, etc.)
- **Versions:** Versions prior to 125.0.6422.141
- **Configurations:** Systems running WebAssembly Garbage Collection (Wasm-GC) features.
## Vulnerability Description
The vulnerability stems from a specification violation within the `DefaultReferenceValue()` function in the V8 engine. According to the Wasm-GC specification, only `null` values are permitted as default values for reference types. However, the function was incorrectly returning `undefined` for two specific types, including `nullexternref`.
This violation breaks critical engine invariants. Optimizing compilers (like TurboFan) rely on these invariants to make assumptions about data ranges and types. When `kNoExtern` is treated as `undefined` rather than `null`, the compiler may generate incorrect machine code, leading to type confusion or memory corruption. Specifically, this allows for the creation of malformed objects, such as strings with invalid lengths.
## Exploitation
- **Status:** PoC explored/available; targeted in security research.
- **Complexity:** High
- **Attack Vector:** Network (Remote via malicious website)
## Impact
- **Confidentiality:** High (Potential for memory leakage)
- **Integrity:** High (Type confusion can lead to arbitrary code execution)
- **Availability:** High (Can cause browser crashes/instability)
## Remediation
### Patches
- Update Chromium-based browsers to version **125.0.6422.141/.142** (Windows/Mac) or **125.0.6422.141** (Linux) or later.
### Workarounds
- Disable WebAssembly support in the browser settings or via enterprise policy if updates cannot be immediately applied (not recommended for general use due to site breakage).
## Detection
- **Indicators of compromise:** Unusual browser crashes when interacting with complex Wasm applications.
- **Detection methods and tools:** Security scanners should check for outdated versions of the V8 engine or Chromium binaries. Monitor for attempts to trigger Wasm-GC features from untrusted domains.
## References
- Google Chrome Releases: hxxps[://]chromereleases[.]googleblog[.]com/2024/05/stable-channel-update-for-desktop_30.html
- Chromium Bug Tracker: hxxps[://]issues[.]chromium[.]org/issues/340927583
- V8 Project: hxxps[://]v8[.]dev/