The Chromium issue is not public yet, so let's go with a very simple example.
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).
I appreciate the thorough explanation... you seem to understand the domain... but I still don't get how this would work in practice. My experience with C/C++ is somewhat limited but I imagine V8 does something like reserve a whole bunch of addresses and then manage them itself, with some internal list where script arrays/objects correspond to blocks. Or maybe it delegates some of that to C++ vectors that can scale up. But what scripted integer or array could you pass it that would access anything already freed or outside the bounds of the addresses that array was mapped to? The only thing I can think is some kind of asynchronous wipe that would allow the engine to write other data to that block, and using a race condition to access it after it was free. But that doesn't sound quite like a type confusion.
What's an actual snippet of pseudo-JS that could make the engine overrun its memory and start reading out of arbitrary addresses, even within the sandbox? Wouldn't that have been accounted for in the most basic design?
I'll have to note that I'm probably way worse than anyone doing this professionally or semi-professionally. This is the extent of what I learned as part of university, which was exclusively using planted vulnerabilities. The knowledge required to find and exploit such issues in a real-world scenario goes much deeper. My dayjob in security is on the entirely opposite side, since I'm doing defensive security on the system-level.
In short, it is quite likely that someone may join in and point out where my information is outdated or plain wrong. (Please do so!)
> My experience with C/C++ is somewhat limited but I imagine V8 does something like reserve a whole bunch of addresses and then manage them itself [...]
That is essentially correct, that's what the 4 Gigabyte allocation I mentioned before is. Let's call it the "v8 heap", because it is distinct from the heap that your system manages (which is the one used for `malloc` and `new`), but it will largely work in the same way.
> [...] with some internal list where script arrays/objects correspond to blocks.
v8 does have a lot of internal checks to make sure that what it is touching looks sane (at least on debug builds), but it will not have a lot of duplicated information. Having to check or update information in multiple places is both an artificial limit on performance as well as its own source of bugs (if not kept in sync correctly).
If v8 needs a JavaScript Object then it will simply ask the v8 heap for an appropriately sized memory allocation and fill in its data there, not unlike normal C or C++ objects (except that v8 usually refcounts, I believe). After this it will simply continue to work with the pointer that it already has.
> But what scripted integer or array could you pass it that would access anything already freed or outside the bounds of the addresses that array was mapped to?
You need to keep in mind that in this scenario, reading/writing outside the intended memory area is already the effect that we want to achieve, it is not the vulnerability.
We are not abusing some insufficient bounds check on an existing Array, _we make v8 believe that there is an Array_ (or at the very least something that it can use like one; in either case it's completely made up), and it happens to have its data stored at the location and length that we want.
> Wouldn't that have been accounted for in the most basic design?
Yes, and for that reason the interpreter itself is considered pretty much battle-tested. However, in search for more performance, multiple JavaScript engines have turned towards engineering Just-In-Time compilers to accelerate running code that runs so often that the compile overhead is worth it. v8 / Chromium / Google alone have a set of three JIT compilers (Sparkplug, Maglev, TurboFan) that compile interpreter bytecode to actual machine instructions depending on what is currently required and how fast the resulting code should be.
> What's an actual snippet of pseudo-JS that could make the engine overrun its memory and start reading out of arbitrary addresses, even within the sandbox?
Those are a bit hard to come by, even more so since the focus for v8 exploitation has changed to targeting the JIT compilers. This usually means that a lot of the exploit would be concerned with wrangling the compiler into place.
I'll try to give an example of what a type confusion involving the JIT compiler looks like, but this is based on work by my classmates, since I never finished that particular part of the exercise.
It is also recited purely from recollection, since I'm not near my university notes.
To get the best possible code optimization the compiler wants to work with some assumptions. If any of those don't hold anymore, the compiler should either never have optimized or at the very least it should deoptimize before anything happens and fall back to a more flexible way of running that code.
One such nugget of information is whether certain well-known properties (let's say .name) can have side effects, those are kept as lists in the source code of the compiler [1]. If the compiler is told that .name can not mutate its object (contrary to the specification and the remainder of the v8 implementation), then it may choose to elide type change checks within the optimized function (that has already been optimized for a specific type) and miss a deoptimization.
If v8 then uses the optimized function after it should have been deoptimized, we essentially get a function that uses an area of memory as if it were a different type of object.
PS: I should get back into this, even just explaining already-done things sounds fun.
Wow. If I understand, your .name example kinda blows my mind. So that would be where the JIT compiler might be pre-optimized to expect a certain length for a supposedly immutable parameter... right? Even if the spec makes everthing mutable. I didn't know that was part of the optimization, but it makes some sense.
That makes it possible for me to visualize how a use-after-free might work inside a JIT engine's sandbox. If I'm not misunderstanding, you're saying that the type confusion attack could be accessed by changing something as simple as the prototype for Object, in a way that the JIT compiler was hardcoded to ignore? Essentially that the compiler is not built to spec, and then getting the garbage collector to somehow free the extra memory, it's still possible to open a hole to read sequential blocks. But the main flaw would be that the compiler reserves X memory for quickly writing an object and then in some unoptimized phase sees that the object only took up X-y and reuses a portion of it...?
I'm a high school dropout..Am I seeing this right?
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).