JIT-Picking: Exploiting the Logic Gap in Modern JavaScript Engines

#security #javascript #fuzzing #browsers

Introduction

JavaScript has evolved from a simple scripting language into the backbone of the modern web. Today’s browsers rely on massive, hyper-optimized engines such as V8 (Chrome), SpiderMonkey (Firefox), and JavaScriptCore (Safari).

To achieve native-like performance, these engines employ Just-In-Time (JIT) compilers, transforming hot code paths into optimized machine code. However, this relentless pursuit of speed has created a vast attack surface. Beyond traditional memory-safety bugs lies a quieter and more dangerous class of vulnerabilities: silent JIT miscomputations.

These logic flaws often evade conventional security oracles, yet they can be weaponized into powerful remote code execution primitives.

The Problem

Securing JIT engines is uniquely difficult because most testing methodologies are blind to semantic correctness. Traditional fuzzing strategies fall short for several reasons:

Silent Failures
A JIT optimization may incorrectly assume a variable is always a positive integer. The program continues executing but produces subtly wrong results—often eliminating bounds checks and enabling out-of-bounds memory access.
Sanitizer Blindness
Tools like ASAN instrument the engine’s C++ host code, not the dynamically generated machine code emitted by the JIT compiler.
Cross-Engine Noise
Differential testing across engines (e.g., V8 vs. JSC) produces excessive false positives due to implementation-defined behavior permitted by the ECMAScript standard (e.g., Array.sort()).

The Solution: JIT-Picking

JIT-Picking introduces a precision-focused differential fuzzing architecture by turning a JavaScript engine against itself.

Differential Oracles
The same JavaScript input is executed twice:
- Instance A: Interpreter-only mode (stable, conservative)
- Instance B: JIT-enabled mode (aggressive, optimized)
Probe Injection

The fuzzer injects calls to a custom probe_state() function, capturing the values of local variables during execution.
Execution Hashing

All probed values are serialized into a single execution hash. Any mismatch between the interpreter and JIT runs signals a miscomputation.
Transparent Probing

Probes are embedded directly into the engine’s IR (MIR/LIR) to prevent the optimizer from eliminating them—without suppressing the optimizations under test.

Technical Deep Dive

“By turning the JavaScript engine against itself, we create a domain-specific bug oracle. We no longer wait for crashes; we alert on the smallest semantic deviation.”

This approach excels at detecting bugs in loop optimizations, where logic errors may occur during intermediate iterations and disappear by program termination.

By distributing probes throughout execution rather than only at the end, JIT-Picker captures transient miscomputations that traditional fuzzers never observe.

Key Findings & Impact

A 10-month evaluation against production-grade engines revealed the effectiveness of JIT-Picking:

Engine	Total Bugs Found	JIT-Specific Bugs	Status
V8 (Chrome)	1	1	Patched
JavaScriptCore (Safari)	14	12	Patched / Reported
SpiderMonkey (Firefox)	17	14	Patched
Total	32	27	$10,000 Mozilla Bounty

The Architect’s Mandate

As software complexity increases, generic crash oracles are no longer sufficient.

For speculative, optimizing systems like JIT compilers, every miscomputation must be treated as a potential exploit primitive. The future of browser security lies in semantic-aware testing—tools that understand not just whether code runs, but how it is transformed by the compiler.

Secure browsers require treating logic correctness as a first-class security boundary.

🗣️ Discussion

With the rise of WebAssembly and increasingly aggressive JIT tiers:

Should automated differential testing become mandatory in browser CI/CD pipelines?
How would you manage the performance overhead of deep semantic probing in production-scale engines?

Let’s talk JIT security in the comments 👇