What You Will Learn
This blog aims to:
- Give you a landscape view of the browser exploitation realm.
- Give you some pointers on how to get started in browser exploitation.
Prerequisites
Before reading this, it’s gonna be good to:
- Have some low level knowledge (e.g previously coded in
C/C++). - Know how to code in
JavaScriptis also a plus.
Why Would I Learn This?
Incentives motivate work
So why would you consider browser hacking, why would you even bother to learn how that black box works?
Let me give you a couple of reasons:
- It puts bread on the table, i.e you can get up to $250,000 bounties while doing this kind of stuff💰.
- It can even help you while doing you’re day to day programming — yes while you’re writing the next JS framework! —, knowing how things work at a bare metal level, can really you even with the most abstract languages, case in point, is there a difference between these two loops performance wise?
for (let i = 0; i < n; ++i) {
for (let j = 0; j < n; ++j) {
for (let k = 0; k < n; ++k) {
C[i][j] += A[i][k] * B[k][j];
}
}
}
for (let k = 0; k < n; ++k) {
for (let j = 0; j < n; ++j) {
for (let i = 0; i < n; ++i) {
C[i][j] += A[i][k] * B[k][j];
}
}
}
- Teaches you how to handle complexity, embrace abstraction, and cope with a high probability of failure.
- “Aesthetically pleasing” - Alisa Esage, popping a shell is always fun to see, but there is something about popping a shell by just entering a website in the address bar.
How Browsers Work?
Browsers can be thought of as almost independent machines, i.e. they run programs (aka websites), render UIs, handle different users, etc. This might even have been the motivation behind projects like Chromium OS and Firefox OS (now discontinued), though they didn’t succeed—after all, you can’t just overtake well-established, operating systems overnight anyways 🤷♂️.
Nonetheless, browsers are incredibly complex and beautifully engineered pieces of software, and their architecture is worth exploring.
We’ll be focusing on the Chromium browser (since I’ve had some experience with its low-level implementation, particularly its JavaScript engine-but let’s not get ahead of ourselves).
A picture diagram is worth a hundred words, so here’s a diagram outlining the major components of Chromium’s architecture, I used the three dots to abstract away the scary IPC (Inter-process communication woo woo 👻), which we won’t be discussing for now:
┌──────────────────────────────────────────────────────────────┐
│ Chromium Browser │
├──────────────────────────────────────────────────────────────┤
│ ┌─────────────┐ ┌─────────────┐ ┌───────────────────────┐ │
│ │ ┌─────────┐ │ │ Renderer │ │ GPU Process │ │
│ │ | ... | │ │ (Blink + │ │ (Graphics │ │
│ │ └─────────┘ │ │ V8) │ │ Acceleration) │ │
│ └─────────────┘ └─────────────┘ └───────────────────────┘ │
│ ┌──────────────┐ ┌─────────────┐ │
│ │ Network │ │ Storage │ │
│ │ (Net Stack) │ │ (Cache, │ │
│ └──────────────┘ │ Cookies) │ │
│ └─────────────┘ │
└──────────────────────────────────────────────────────────────┘
We will be discussing the renderer process, in particular, the V8 component.
Now How Does V8 Work?
Why are we looking at the V8 component specifically you ask? because it’s the most interesting one, from an attacker perspective, it’s where a whole language (Javascript) gets evaluated, and JIT-ed, and the thing about JIT compilation is that you can’t avoid memory corruption by just employing a memory safe language (e.g Rust), it’s code generation logic that might lead to such vulnerabilities, not the code itself (at least not as frequently cmiiw), that’s why the V8 team, keeps using C++ as of today.
Here is a diagram illustrating a general view of the V8 pipeline workflow:
┌─────────────────────────────────────────────────────────────┐
│ V8 JavaScript Engine │
├─────────────────────────────────────────────────────────────┤
│ ┌───────────────────────┐ ┌───────────────────────────┐ │
│ │ Parser │ ─► │ Abstract Syntax Tree │ │
│ │ (Converts JS to AST) │ │ (AST) │ │
│ └───────────────────────┘ └───────────────────────────┘ │
│ ▼ │
│ ┌───────────────────────┐ ┌───────────────────────────┐ │
│ │ Ignition │ ◄─ │ Bytecode Generator │ │
│ │ (Interpreter) │ │ (Converts AST to Bytecode)│ │
│ └───────────────────────┘ └───────────────────────────┘ │
│ ┌──────────────────┐ ▼ │
│ ┌──┘ Maglev/Sparkplug └─┐ ┌───────────────────────────┐ │
│ │ Turbo(Fan/Shaft)/... │ ◄─ │ Profiler (Hot Code) │ │
│ │ (Optimizing Compiler) │ │ (Monitors Execution) │ │
│ └───────────────────────┘ └───────────────────────────┘ │
│ │
│ ┌───────────────────────┐ ┌───────────────────────────┐ │
│ │ Orinoco │ ◄─ │ Garbage Collector │ │
│ │ (Memory Management) │ │ (Heap Cleanup) │ │
│ └───────────────────────┘ └───────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
Okay, I guess, but as we know it’s the case with Javascript, “Everything is an Object”—at least mostly, so how are objects are stored in the memory?
Well, as the saying goes “Things are known by their opposites”, so let’s see how is a low level language: C, differ from an abstract language: Javascript:
┌─────────────────────────────────────────────────────────────────────────────────────┐
| | C (Low-Level) | JavaScript (Abstract) |
├───────────────────────+──────────────────────────────+──────────────────────────────┤
| Memory Management | Manual (malloc/free) | Automatic (Garbage Collected)|
| | Uses glibc heap | Uses V8 heap |
├───────────────────────+──────────────────────────────+──────────────────────────────┤
| Object Representation | Structs saved as-is in | Objects are complex |
| | contiguous memory | spec-defined[^1] structures |
| | (e.g., `struct {int x;}`) | (e.g., hidden classes, maps) |
├───────────────────────+──────────────────────────────+──────────────────────────────┤
| Execution Model | Compiled to native machine | [JIT-compiled] (e.g., V8 |
| | code (no runtime) | Ignition/TurboFan) |
├───────────────────────+──────────────────────────────+──────────────────────────────┤
| Type System | Static (fixed at compile | Dynamic (types inferred |
| | time) | at runtime) |
└───────────────────────+──────────────────────────────+──────────────────────────────┘
[^1]: https://262.ecma-international.org/
Let’s look at an example of an array of floats:
┌───────────────────┐ ┌─────────────────────────────────────────┐
│ JS Code │ │ V8 Heap │
├───────────────────┤ ├─────────────────────────────────────────┤
│ const arr = │ | ┌─────────────────────────────────┐ │
│ [1.1, 1.2, 1.3];│────────▶ │ JSArray (arr) │ │
└───────────────────┘ │ ├─────────────────────────────────┤ │
│ │ - HiddenClass (Map) │ │
│ │ - ElementsKind: DOUBLE_ELEMENTS │ │
│ │ - Length: 3 │ │
│ │ - Elements ───────────────────┼──┐ |
│ └─────────────────────────────────┘ │ │
│ │ │
│ ┌─────────────────────────────────┐ │ │
│ │ FixedDoubleArray │◀─┘ │
│ ├─────────────────────────────────┤ │
│ │ - [0]: 1.1 │ │
│ │ - [1]: 1.2 │ │
│ │ - [2]: 1.3 │ │
│ └─────────────────────────────────┘ │
└─────────────────────────────────────────┘
Pointer Compression
Let’s talk about pointer compression, because that’s what enabled (or at least in my understanding helped) with pointer sandboxing that we will be discussing later.
Well you might be used to 64 bits addresses, but in V8 heap, they announced (around 2018 IIRC) pointer compression, which is basically just saving the lower 32-bits of each pointer (offset), while the higher 4-bytes are saved to a register (r14 on x86), for fast access, so the pseudo-code for “uncompressing” a “sandbox” pointer can be stated as this: full_pointer = base_address | (compressed_pointer & 0xFFFFFFFF).
Pointer Tagging
There is also the concept of pointer tagging, to distinguish between Smi (immediate small integer) and a HeapObject (anything allocated in the V8 heap inherits from this), this is very simple, the LSB bit can be either 0 (Smi) or 1 (HeapObject).
┌────────────────────────────┐
│ 32-bit Compressed Pointer │
├────────────────────────────┤
│ [31........1][0] │
│ Offset Tag │
└────────────────────────────┘
Careful reader will recognize that this poses that V8 heap will be limited to 4GB, which is true, but fortunately V8 has already a 2GB/4GB limit even before this mechanism has been deployed.
The Optimization Pipeline
Overview
Before learning how V8 bugs gets introduced, having an idea about it’s optimization pipeline.
Let’s look at an example at how a javascript function gets optimized down to machine code:
┌───────────────────────────┐
│ JavaScript Source │
├───────────────────────────┤
│ function calc(a, b) { │
│ const sum = a + b; │
│ const prod = a * b; │
│ return sum; │
│ } │
└───────────────────────────┘
▼
┌──────────────────────────────┐ ┌───────────────────────────────┐
│ Bytecode (Ignition) │ │ Initial IR[^1] (TurboFan) │
├──────────────────────────────┤ ├───────────────────────────────┤
│ Ldar a1 │ │ t1 = Load a │
│ Add a0, [0] │ │ t2 = Load b │
│ Star0 │ │ t3 = Add t1, t2 │
│ Ldar a1 │ │ Store sum = t3 │
│ Mul a0, [1] │ ─► │ t4 = Load a │
│ Star1 │ │ t5 = Load b │
│ Ldar r0 │ │ t6 = Mul t4, t5 │
│ Return │ │ Store prod = t6 │
└──────────────────────────────┘ │ t7 = Load sum │
│ Return t7 │
└───────────────────────────────┘
▼
┌──────────────────────────────────────┐
│ Optimized IR (After DCE[^2]) │
├──────────────────────────────────────┤
│ t1 = Load a │
│ t2 = Load b │
│ t3 = Add t1, t2 │
│ Return t3 │
└──────────────────────────────────────┘
▼
┌──────────────────────────────────────┐
│ Final Machine Code │
├──────────────────────────────────────┤
│ mov rax, [a] │
│ add rax, [b] │
│ ret │
└──────────────────────────────────────┘
[^1]: Intermediate representation
[^2]: Dead-code elimination
Ignition’s bytecode isn’t currently in our interest, but it’s quite self explanatory once you know that ignition’s machine is register-based, with an accumulator register, and that Lda/Sta Loads/Stores to that accumulator, ai registers holds the arguments passed to the function.
Other forms of optimizations can also happen, let’s recall a couple of those:
Common subexpression elimination
┌───────────────────────┐ ┌───────────────────────┐
│ Original IR │ │ Optimized IR │
│ │ │ │
│ t1 = Load a │ │ t1 = Load a │
│ t2 = Load b │───►│ t2 = Load b │
│ t3 = Add t1, t2 │ │ t3 = Add t1, t2 │
│ t4 = Load a │ │ t4 = t1 │ // Reuse t1
│ t5 = Load b │ │ t5 = t2 │ // Reuse t2
│ t6 = Add t4, t5 │ │ t6 = t3 │ // Reuse t3
└───────────────────────┘ └───────────────────────┘
Inline expansion
┌───────────────────────┐ ┌───────────────────────┐
│ Caller Function │ │ Inlined IR │
│ │ │ │
│ t1 = Call foo(a, b) │───►│ t1 = Add a, b │ // foo() inlined
│ ... │ │ ... │
└───────────────────────┘ └───────────────────────┘
Loop-invariant code motion
┌───────────────────────┐ ┌───────────────────────┐
│ Original Loop │ │ Optimized Loop │
│ │ │ │
│ while (i < n) { │ │ t1 = Load x │ // Hoisted
│ t1 = Load x │───►│ while (i < n) { │
│ t2 = Add t1, i │ │ t2 = Add t1, i │
│ } │ │ } │
└───────────────────────┘ └───────────────────────┘
When It Breaks
JIT Typer Bugs
Typer bugs are a class of vulnerabilities that arise from incorrect type or range analysis during JIT optimization. V8 predicts variable types and value ranges to enable optimizations. If it makes wrong assumptions, it can lead to eliminated security checks.
Let’s see an example of these typer bugs.
function f(x) {
var arr = [1.1, 1.2];
var y = 0; // y0
if (x == "foo") y = 1; // y1
// y2 = phi(y0, y1)
y = y + 1; // y3 = y2 + 1
return arr[y];
}
The comments represent how the variables are gonna be assigned in the SSA (Static single-assignment form) form which is used by Turbofan, variables can be assigned only once in the said form.
The Phi function merges two or multiple possibilities, choosing one of them depending on the previous control flow.
Below is a CFG (Control-flow graph) in an SSA form.
┌────────────────────┐
│ x == "foo" │
└──────┬──────┬──────┘
│ │
Yes │ │ No
│ │
┌─────────────┘ └─────────┐
│ │
┌──────┴────────┐ ┌──────┴─────────┐
│ y0 = 0 │ │ y1 = 1 │
│ Range(0, 0) │ │ Range(1, 1) │
└──────┬────────┘ └───────┬────────┘
│ │
└────────────────┬──────────────┘
▼
┌────────────────────────┐
│ y2 = Phi(y0, y1) │
│ Range(0, 1) │
└───────────┬────────────┘
▼
┌──────────────────────────┐
│ y3 = SpecSafeAdd(y2, 1) │
│ Range(1, 2) │
└──────────────────────────┘
y3 type (Range(1, 2)) is perfectly correct, but let’s assume SpecSafeAdd is erroneous, i.e., it updates the Range minimum but not the maximum, below is the updated node:
...
▼
┌──────────────────────────┐
│ y3 = SpecSafeAdd(y2, 1) │
│ Range(1, 1) │
└──────────────────────────┘
Now we have a problem, which is that y3.Max is assumed to be 1 , which is in the range of the arr , this means when the function is compiled, when we invoke the function with x == “foo” , y will have a value of 2 and at the return, we will get arr[2] effectively having an out-of-bound read.
What about out-of-bound write?
function f(x, w) {
var arr = [1.1, 1.2];
var y = 0;
if (x == "foo") y = 1;
y = y + 1;
arr[y] = w;
}
Yeah.
Exploitation
So we have an out-of-bound r/w, it’s eventually just a byte/few bytes access, we need more reach, and more power, to have exactly that, in browser exploitation it’s very common after you get a memory corruption vulnerability, to develop two primitives: addrof/fakeobj .
addrof
The goal of this primitive — practically a function — is that you pass it an object, and you get it’s address of that object inside the V8 heap.
┌───────────────────────────┐ ┌──────────────────────────┐
│ JavaScript │ │ V8 Heap │
├───────────────────────────┤ ├──────────────────────────┤
│ │ │ │
│ let obj = {x: 42}; ────────0x158f...─┌───────────────────┐ │
│ │ │ │ JSObject (obj) │ │
│ let addr = addrof(obj); │ │ │ - map: 0x... │ │
│ │ │ │ - properties: ... │ │
│ // addr = 0x158f00040321 | │ │ - elements: ... │ │
└───────────────────────────┘ │ └───────────────────┘ │
└──────────────────────────┘
fakeobj
The goal of this primitive is to pass it an address, that you already have setup-ed a valid object that array and it will return to that object in the javascript world, and you’ll ultimately have control over that object’s backing store (e.g elements address of an array), thus having control where to write/read in all of the V8 heap.
┌─────────────────────────────────┐ ┌────────────────────────────────────┐
│ JavaScript │ │ V8 Heap │
├─────────────────────────────────┤ ├────────────────────────────────────┤
│ │ │ │
│ var arr = [1.1, 1.1, ─── 0x158f...──┌───────────────────┐ │
│ map<<4|properties, │ │ │ JSArray (arr) │ │
│ length<<4|elements] │ │ │ - map: 0x... │ │
│ │ │ │ - properties: ... │ │
│ var addr = addrof(arr); │ │┌─┤ - elements: ... │ │
│ // addr = 0x158f00040321 │ ││ └───────────────────┘ │
│ │ ││ ┌───────────────────────────────┐ │
│ fake_arr = fakeobj(addr + ─────────────┴─┤ Fake JSArray (arr's elements)│ │
│ 0x...) │ │ │ - map: 0x... │ │
│ │ │ │ - properties: ... │ │
│ │ │┌─┤ - elements: ... │ │
│ │ ││ └───────────────────────────────┘ │
│ │ ││ ┌───────────────────────────┐ │
│ │ ││ │ WasmTrustedInstanceData │ │
│ fake_arr[0] ──────────────────────────────┴───┤ - jump_table_start: 0x... │ │
│ │ │ │ (wasm rwx page) │ │
│ │ │ │ │ │
│ │ │ └───────────────────────────┘ │
└─────────────────────────────────┘ └────────────────────────────────────┘
With these two primitives in you’re tool belts, it’s just a matter of writing you’re shell-code, to say, a WASM rwx page, et voila!
You’re Starter Pack
When doing V8 research, debugging is a must, this is my goto docker image:
FROM ubuntu:22.04 as build
RUN apt-get update && apt-get -y upgrade
RUN apt-get install -yq --no-install-recommends build-essential git ca-certificates python3-pkgconfig curl python3
RUN git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git /opt/depot_tools
ENV PATH="/opt/depot_tools:${PATH}"
RUN mkdir /build
RUN cd /build && fetch v8 && cd v8 && git checkout 247d42b64689fe03fea5949373b3f0d0daa81375 && gclient sync
RUN cd /build/v8 && gn gen out/release --args='is_debug=false target_cpu="x64" v8_symbol_level=2 v8_enable_backtrace=true v8_enable_dissembler=true v8_enable_object_print=true v8_enable_verify_heap=true v8_enable_sandbox=true' && \
autoninja -C out/release d8
The V8 Cage
It turns out that making things more complicated can also be a way of solving problems—and that’s exactly the case with this new security feature introduced by the V8 team. The core idea is to ‘remove any unboxed pointers in the V8 heap’ and instead rely on indices into lookup tables that contain the actual unsandboxed pointers.
Let’s see how is that relevant to the most two important components that are traditionally used in the exploitation chain.
Function—Wise
Previously, JSFunction objects contained relative pointers to CodeDataContainer objects, which in turn held raw pointers to JIT-compiled code - enabling JIT spraying attacks. The sandbox now replaces raw pointers with indices into a trusted code pointer table (outside the V8 heap), effectively eliminating1 these kinds of attacks.
Before
┌─────────────────────────┐
│ V8 Sandbox │
├─────────────────────────┤
│┌───────────────────────┐│ ┌───────────────────────┐
││ JSFunction ││ │ Code │
││ (V8 Heap rw-) │──────►│ (JIT-compiled r-x) │
││ ││ │ │
││ - [[Code]]: ││ │ push rbp │
││ *Direct pointer* ││ │ mov rbp, rsp │
│└───────────────────────┘│ │ sub rsp, 0xc0 │
└─────────────────────────┘ └───────────────────────┘
After
┌─────────────────────────┐
│ V8 Sandbox │
├─────────────────────────┤
│┌───────────────────────┐│ ┌───────────────────────┐ ┌───────────────────────┐
││ JSFunction ││ │ Code Pointer Table │ │ Code │
││ (V8 Heap rw-) ││ │ (in trusted space) │──────►│ (JIT-compiled r-x) │
││ ││ │ │ │ │
││ - [[Code]]: ││ │ Entry 0: 0xABC123 │ │ push rbp │
││ *Index into table* │──────►│ Entry 1: 0xDEF456 │ │ mov rbp, rsp │
││ (e.g., "Entry 1") ││ │ Entry 2: 0xGHI789 │ │ sub rsp, 0xc0 │
│└───────────────────────┘│ └───────────────────────┘ └───────────────────────┘
│ │
└─────────────────────────┘
WASM—Wise
WASM instances also used to hold relative pointers to WasmTrustedInstanceData, which in turn hold an unsandboxed pointer to the WASM rwx page, but now it hold external table indices.
Before
┌─────────────────────────────────────────────────────────────┐
│ V8 Sandbox │
├─────────────────────────────────────────────────────────────┤
│ ┌───────────────────────┐ ┌───────────────────────┐ │
│ │ WASM Module │ │ WASM Instance │ │
│ │ │──────►│ │ │
│ │ - Exported Functions │ │ - CodeTable: │ │
│ │ (Sandboxed Pointer) │ │ *Raw pointers* │ │
│ └───────────────────────┘ └──────────┬────────────┘ │
│ | │
│ | │
└─────────────────────────────────────────────|───────────────┘
▼
┌───────────────────────────────────────────────────────┐
│ RWX Memory (Outside Sandbox) │
│ - JIT-compiled WASM instructions │
└───────────────────────────────────────────────────────┘
After
┌─────────────────────────────────────────────────────────────┐
│ V8 Sandbox │
├─────────────────────────────────────────────────────────────┤
│ ┌───────────────────────┐ ┌───────────────────────┐ │
│ │ WASM Module │ │ WASM Instance │ │
│ │ │──────►│ │ │
│ │ - Exported Functions │ │ - CodeTable: │ │
│ │ (Sandboxed Pointer) │ │ *Indices* │ │
│ └───────────────────────┘ └──────────┬────────────┘ │
│ | │
│ | │
└─────────────────────────────────────────────|───────────────┘
▼
┌───────────────────────────────────────────────────────┐
│ Trusted Pointer Table (External) │
│ - Entry 0: 0x1B15ABC123 (Tag + Address) │
│ - Entry 1: 0x1B15DEF456 │
└───────────────┬───────────────────────────────────────┘
|
▼
┌───────────────────────────────────────────────────────┐
│ RWX Memory │
│ - JIT-compiled WASM instructions │
└───────────────────────────────────────────────────────┘
With these mitigations in place, exploitation is yet another step away.
DYIs
Hacking TVs?
Most modern TVs come with a browser. For example, the TV in our room has an ancient one — yes, 2016 is ancient in browser terms. So we can practice our newly learned skills on products like these.
Doing Some 🎩
Of course, I’m joking, but surprisingly, it’s not very common for many headless browsers out there to get updated. Case in point: here’s the User-Agent of a third-party service (we found it being used by one of the multimillion-user platforms out there) endpoint bot:
Going Further
We’ve just scratched the surface of the iceberg, if you want to go further into this area of hacking, try doing this pwn.college dojo (that’s how I started), and if you’re looking for some resources, I’ve been collecting some V8 resources, you can check it out, other than that, until the next time!
-
“eliminating” is a stretch. ↩