Skip to content
KitploitKITPLOIT
ToolsBlog
Submit
ToolsBlog
Submit

Hacking, PenTest, and Cybersecurity Tools for Your Security Arsenal!

Kitploit is a directory of hacking, cybersecurity, and pentesting tools. Discover the latest project updates to find vulnerabilities, analyze systems, automate testing, and strengthen your security.

··Feeds·Contact·Privacy·© 2026 Kitploit

Tool Directory

Categories

View all categories
Loading categories
CVE-2024-29943-but-with-wasm — CVE-2024-29943, but with wasm | Kitploit
Tools/GitHubGitHub/sneakynachos/cve-2024-29943-but-with-wasm
ExploitationShellcodeWeb SecurityBinary Exploitation
GitHubsneakynachos/cve-2024-29943-but-with-wasm

CVE-2024-29943-but-with-wasm

CVE-2024-29943, but with wasm

View Repository

Most Popular

View all →

Discover the most used tools by our community.

Explore all tools

Browse our collection of tools

View all tools →
119 days agoNot yet reviewed
Share

CVE-2024-29943, but with wasm

An end-to-end exploit chain for CVE-2024-29943 that achieves arbitrary native code execution by smuggling shellcode into SpiderMonkey's WebAssembly JIT code page as f64.const immediates — no ROP, no VirtualProtect, no external toolchain.

Verified working against the SpiderMonkey shell from the 2024-03-20 mozilla-central nightly (JavaScript-C126.0a1, linux x86-64, pre-fix): the chain runs to completion and the payload executes (write(1, "PWNED by wasm!\n"); exit(0)).

The vulnerability

CVE-2024-29943 is a sec-critical IonMonkey range-analysis bug used at Pwn2Own 2024 by Manfred Paul, affecting Firefox < 124.0.1 (Bugzilla 1886849, CVSS 9.8).

MObjectKeysLength::computeRange returned an incorrect integer range for Object.keys(x).length after Object.keys was made elidable (regressed by bug 1845728). Ion range analysis concluded a loop counter could not go negative and eliminated bounds checks that were still reachable, yielding an out-of-bounds read/write on a .

Uint8Array

Chain

root@kitploit:~
Object.keys range-analysis bug -> OOB r/w on Uint8Array
  -> corrupt adjacent ArrayBuffer -> addrof / fakeobj / arbitrary R/W
    -> instantiate hand-built WASM module (shellcode as f64.const immediates)
      -> WasmInstanceObject -> wasm::Instance -> wasm::Code -> CodeTier
         -> ModuleSegment.bytes_ (the JIT code page, RX)
           -> scan page for marker constant
             -> overwrite FuncExport.eagerInterpEntryOffset_ (plain heap)
                with the shellcode's offset within the page
               -> call the export through the interpreter -> payload runs

Two details cost us a segfault each to learn, so they're written down:

  1. The code page is RX, not RWX. SpiderMonkey mprotects the wasm code segment after compilation; patching instructions in place faults. The redirect is done by overwriting eagerInterpEntryOffset_ in the heap-resident FuncExport instead — the interpreter computes codeBase + offset and jumps there.
  2. The trigger call must come from the interpreter. Top-level code is hot from the primitive-training loop and gets Warp-compiled, which calls wasm exports through the JIT-entry path and never looks at the interp entry offset. Calling from a cold function forces the interpreter path.

The WASM-JIT-page shellcode technique is from WasmBlazeFox; this repo demonstrates that the technique composes with a modern, shipping-browser bug in place of the original 2018 training bug.

Files

  • poc.js — minimal trigger for the range-analysis bug.
  • exploit.js — full chain: primitives + WASM JIT shellcode stage.
  • gen_wasm.py — assembles the WASM module embedding shellcode and verifies the constant round-trip. python3 gen_wasm.py mysc.bin to use a different payload. The default payload is a pure-syscall write(1, "PWNED by wasm!\n"); exit(0) proof that needs no symbol resolution (so it also works in the bare jsshell). For the classic libxul-based system("gnome-calculator") payload, see WasmBlazeFox ex6.
  • test.gdb — breakpoints and ptype /o helpers for deriving object-model offsets on a given build.

Reproducing

  1. Get a vulnerable shell: build gecko-dev @ afbdf6822c9e9f9b6d44b9ea6904cb10878126b1 (Firefox ~124, pre-124.0.1), Linux x86-64 — or grab a pre-fix nightly jsshell, e.g. archive.mozilla.org/pub/firefox/nightly/2024/03/2024-03-20-21-16-35-mozilla-central/jsshell-linux-x86_64.zip.
  2. Run:
    root@kitploit:~
    LD_LIBRARY_PATH=<jsshell dir> ./js --no-threads --ion-offthread-compile=off \
    --spectre-mitigations=off poc.js      # trigger only (segfault)
LD_LIBRARY_PATH=<jsshell dir> ./js --no-threads --ion-offthread-compile=off \
    --spectre-mitigations=off exploit.js  # full chain ("PWNED by wasm!")

--spectre-mitigations=off is required because the bounds-check elimination relies on index masking being disabled (see the Bugzilla comments).

Notes

  • The wasm export is called exactly once before the hijack so the function stays in the baseline tier, where f64.const immediates are emitted inline in the code segment. Ion compilation could constant-fold them.
  • Offsets (WASM_INSTANCE_OFF_CODE = 0xa8, MetadataTier.funcExports + 448, FuncExport + 8, etc.) were derived from the vulnerable commit's headers and confirmed against the 2024-03-20 nightly jsshell; re-derive with test.gdb for other builds.

References

  • https://bugzilla.mozilla.org/show_bug.cgi?id=1886849
  • https://nvd.nist.gov/vuln/detail/CVE-2024-29943
  • https://www.mozilla.org/security/advisories/mfsa2024-15/
  • https://github.com/bjrjk/CVE-2024-29943
  • https://doar-e.github.io/blog/2018/11/19/introduction-to-spidermonkey-exploitation/
Download Tool