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.
[1] https://chromium.googlesource.com/v8/v8/+/9f30cc5fc4ad6c3236...