Comment by timschumi

Let's say that you have a type confusion bug that (in terms of the interpreted language) allows you to use an Integer variable as an Array.

That sounds nonsensical when just considering the high-level language, but your computer is going to need something to work with when running a script. For an Integer variable it will for example store the value, and for an Array it would store a pointer to a data area (and that area then contains values).

Now, if the interpreter loses track of which type a certain variable is, then it will also not know whether to interpret the internal data as a plain value (arbitrarily chosen by the script/attacker) or a pointer to well-formed data (carefully chosen by the runtime).

As an immediate step, letting the attacker use an address of their choosing for array operations would allow them to read and write arbitrary memory that is reachable with this form of addressing.

I'm putting specific emphasis on "form of addressing" here, because the v8 authors have considered this possibility and put additional protections in place. Within the sandbox, "addresses" are limited to a size of 32 bits, and address within a dedicated 4 Gigabyte area that is specifically for interpreter data. Within that area you are not going to find a lot of critical data to affect outside operations, you'd have to find a way to escape that memory area first.

The next part is going to be a bit hazy because it's been some time since I did Chromium exploitation, and getting code execution within the sandbox from data writes is itself not an easy task.

Now, we have established that there is not a lot of terribly important data within the 4 GB area. The data managing the interpreter lives outside, and any JITed code will also live outside because it needs different access permissions. We only really get to play with Objects and their data.

Objects handling executable code are rare, but there are a few that are at least adjacent. Last time I checked, WASM was one feasible choice where you get reasonably predictable results with custom data, as it included a pointer to actual executable code that represents the WASM program.

Under the assumption that the WASM interpreter/compiler does its job correctly the full block of executable code will not be very interesting. However, any integer constant in the program will end up somewhere within the executable code, and that would give you enough controllable data to encode one or two arbitrary instructions and a relative jump to the next integer constant. To start execution at the first integer constant, we'd then just modify the Object data of the WASM program to slightly offset the entrypoint.

And that's the short form of a possible (and likely outdated) way of getting semi-arbitrary code execution within the sandbox (as we are running as a WASM program, and therefore have all the usual syscall restrictions and other security features engaged).