A serious vulnerability, CVE-2022-43281, was found in wasm-interp (WebAssembly interpreter) version 1..29. This flaw is due to a heap overflow in how the program uses std::vector to handle input, specifically through the std::vector<wabt::Type>::size() function in the standard C++ library file /bits/stl_vector.h.

In this post, we’ll break down what happened, why it matters, and how an attacker might exploit it. We'll also discuss how developers can protect their applications.

What is wasm-interp?

wasm-interp comes with the WebAssembly Binary Toolkit (WABT) — a collection of tools for working with WebAssembly. The wasm-interp tool executes WebAssembly binaries directly, which is great for fast testing and debugging.

More info: WABT GitHub

What is CVE-2022-43281?

CVE-2022-43281 is a heap overflow bug in wasm-interp, discovered in version 1..29. The problem happens in the source code’s use of the C++ STL’s std::vector container. When processing certain types of input, the code fails to properly check the size or memory boundaries, letting attackers overwrite adjacent memory and potentially execute arbitrary code.

Original Advisory: NVD - CVE-2022-43281

How the Vulnerability Works

At the heart of the bug, when wasm-interp parses WebAssembly content, it uses a vector of wabt::Type. The code calls .size() without proper bounds checking. If crafted input tells wasm-interp there are more types than the allocated memory can hold, the code can write past the end of the vector, causing a heap overflow.

Typical vulnerable code structure

std::vector<wabt::Type> types;
// ... parse input, push_back() types ...
auto number_of_types = types.size();  // calculates size, possibly from untrusted data

// Later, code writes data based on number_of_types
for (size_t i = ; i < number_of_types; ++i) {
    // Fails to check if i exceeds the actual allocated size
    types[i] = ...;  // Potential out-of-bounds write!
}

What an Attacker Can Do

If an attacker can get wasm-interp to read a specially crafted .wasm binary containing incorrect type section sizes or sequences, they could:

Example Malicious Input

A simple exploit might involve a .wasm file with a deliberately broken type section that tricks the parser into reporting a huge type count. Because there’s no bounds check before vector access, this can overflow into adjacent heap memory.

Here's an illustrative (not live) snippet in Python that could create such an input

# This python snippet creates a wasm file with a bogus type section size
with open("evil_type_section.wasm", "wb") as f:
    # Minimal wasm header
    f.write(b'\x00asm')         # WASM magic
    f.write(b'\x01\x00\x00\x00') # version 1

    # Faked type section with huge count
    f.write(b'\x01')      # section id: Type
    f.write(b'\x85\x80\x80\x80\x00')  # section size (LEB128 encoded, very large)
    f.write(b'\xFF\xFF\xFF\xFF\xF')  # type count (LEB128-encoded, extremely large)

When wasm-interp tries to parse and store this "enormous" type count, it overflows the vector!

Heap Memory Layout (Diagram)

[ types vector ]  [ other heap data ]
  |----------|---->
           ^ heap overflow here!

Original References

- NVD page: https://nvd.nist.gov/vuln/detail/CVE-2022-43281
- WABT Code: https://github.com/WebAssembly/wabt
- wasm-interp documentation: https://github.com/WebAssembly/wabt/blob/main/docs/wasm-interp.md


## How To Fix / Mitigate

For Users

- Update to the latest version of WABT/wasm-interp as soon as a patch is available.

Add bounds checking before using .size() or indexing vectors with input-derived data.

- Use tools like AddressSanitizer to catch heap overflows in development.

Example Patch (Pseudo-code)

// Before writing to types[i], check that i < types.size()
if (i < types.size()) {
    types[i] = ...;
} else {
    // handle error, reject input
}

Conclusion

CVE-2022-43281 is a classic memory safety bug caused by trusting user input and missing bounds validation around a dynamically allocated vector. It highlights why both automated testing and careful code review around binary parsers are critical, especially in low-level tools like wasm-interp that may end up embedded in security-sensitive environments.

Stay secure, keep your tools updated, and use safe coding practices!

Timeline

Published on: 10/28/2022 21:15:00 UTC
Last modified on: 11/01/2022 16:35:00 UTC