This post is a recorded conference talk on approaching the JavaScript engine inside a browser the way an attacker does. The page carries the video, and the fuller written version of the same material is a separate post on this blog.
The bugs that fill browser vulnerability lists come from one narrow layer: the part compiling JavaScript to machine code guessing a type wrongly, one kind of object taken for another, or a bounds check removed that should have stayed.
Most of the work is reading. The talk is about deciding which parts of a codebase of several million lines are worth opening at all.
The chain it describes ends with code running inside the browser process, still confined by the sandbox around it. Reaching the rest of the machine is a separate problem.
JavaScript engines are now one of the most attacked surfaces of modern operating systems. They run untrusted code from arbitrary websites the moment a tab opens, sit on top of multi-million-line JIT compilers (V8, JavaScriptCore, SpiderMonkey), and have access to a sandbox that, once broken out of, often leads straight to remote code execution on the host. The bug classes that dominate browser CVE lists today (typer mistakes in JIT optimisation, type confusion on object shapes, edge cases in property accessors and bounds elimination) all live inside this layer.
The talk below walks through the general methodology of approaching such an engine for offensive research: how to read the relevant parts of a multi-million-line C++ codebase, how to recognise the primitive shapes that lead to addrof / fakeobj, and how those primitives compose into a renderer-RCE chain.
It was given in French at the Quarks in the Shell 2023 conference, organised by Quarkslab.