Fundamentals of Browser Exploitation

Welcome to the RET2 Fundamentals of Browser Exploitation course!

The following section is a brief overview of the course format, which may be a bit different from other trainings, while the ‘Getting Started’ section covers the practical aspects of going through the training / using this platform.

About the Course

This course is intended for those with some previous experience with exploitation, and provides a strong fundamental background of core browser concepts, enabling researchers to go forth and independently conduct effective vulnerability research and exploit development on modern browsers. The focus is on Google Chrome and Apple Safari.

As opposed to a traditional training, the course has an asynchronous, mostly self-guided format, with three main components.

Written Materials This refers to the lessons themselves, along with exercises applying the relevant knowledge or techniques to the actual JavaScript / browser engines. This is everything that would typically be given in a "textbook" or slide-show format, instead being presented in your browser here on this site.

Virtual Machine A hosted pre-configured VM instance, accessible over SSH and VNC, is provided for working through the exercises or otherwise experimenting with the engine components. The VM has pre-built versions of WebKit / Chromium, some with custom exercise-specific patches applied. This provides the convenience of being able to drop into each JavaScript interpreter with simple one-liners.

Instructor Access Ask an expert any questions you may have, whether you’re stuck on an exercise, need some clarifications, or are curious to learn more about a specific topic. This is the virtual, asynchronous version of an instructor in the room.

Getting Started

Navigating the Materials

The course is comprised of both lesson sections and exercises, which are divided into modules / chapters. Use the sidebar on the left to navigate. Exercises are labeled with an ‘E’ e.g. 1.3.E1.

The natural start is the first section: 1.1.1 Browser Overview and Components

See a full listing here.

Some simpler exercises are done in-browser (e.g. in a JavaScript REPL) while others utilize the VM environment. Feel free to jump right into the material then revisit this page once you reach a point that requires the VM (explained below).

Using your Virtual Machine

To perform the exercises throughout the training, a pre-configured VM is provided for your exclusive use. It will be running Ubuntu Linux and have all the tools you need along with pre-built browser components.

All you need to access the VM is an SSH client and a VNC client.

For SSH: on Linux or macOS you can use the builtin client. Windows also has a builtin client, or you can use PuTTY.

For VNC: we recommend RealVNC Viewer. On Linux, various other clients are likely provided by your package manager. On macOS you can also use the builtin client through the "Screen Sharing" app. If you encounter any weird GUI behavior, you can try a different client. If your client ever fails to connect, try the "Restart VNC Server" button on the VM page (linked below and in top bar).

See the VM page for more info on managing the VM and connecting.

Tmux and Screen are installed if you’d like to use them.

Running Exercises

Exercises use different versions of the browser componenents patched / customized in various ways. Each version exists in a separate container. The exercise command provides the workflow for spinning up each of these exercise-specific environments.

Basic usage is exercise run exercise-name. Most of the exercises only involve the JavaScript engine (jsc or v8), and you’ll be dropped into the corresponding JS REPL.

Some useful options are:

• --debug or --release : run a debug (default) or release build
• --gdb : start a gdb session with the relevant arguments
• --shell : spawn a shell in the container

Additional arguments are passed directly to the binary. For example, exercise run --release jsc --useConcurrentJIT=0 ./ex.js will run a release build of jsc with concurrent JIT disabled, passing a script to execute.

Container Filesystem

Each of the browser engine configurations are in their own containers, and therefore have unique filesystems. The two directories that are mounted and shared between host and each container are /tmp and the home directory (/home/ubuntu).

Any exploit scripts or files needed in the containers should be under one of these directories. Relative paths are fine, e.g. if currently in the home directory writing ex.js, exercise run v8 ./ex.js will work.

A useful consequence of the shared home directory is that configuration files stored there will also apply to the containers. This is most relevant if you’d like to change the GDB configuration in .gdbinit. Feel free to download and use GDB plugins of your choice (pwndbg is present by default).

A Tip for Debugging

When debugging, you’ll likely want to break into the debugger at arbitrary points in your script. There are a couple convenient ways you can do this:

• use builtin breakpoint functions

• jsc: run with --useDollarVM=1 and use $vm.breakpoint()

• v8: run with --allow-natives-syntax and use %SystemBreak()

• read from stdin and ctrl-c into the debugger

• jsc and v8: readline() reads until newline

• set a breakpoint on an otherwise unused function

• this can be useful for debugging the full browser, which may not have the REPL-specific functionality you’d use normally

• e.g. for jsc JSC::mathProtoFuncMax is the native function implementing Math.max