> However, assuming these numbers are simply stored as integers somewhere in the JSObject, an attacker could corrupt one of them to break this invariant. Subsequently, the access into the (out-of-sandbox) std::vector would go out of bounds. Adding an explicit bounds check, for example with an SBXCHECK, would fix this.
Or use Rust
> Encouragingly, nearly all "sandbox violations" discovered so far are like this: trivial (1st order) memory corruption bugs such as use-after-frees or out-of-bounds accesses due to lack of a bounds check
Or use Rust
> Contrary to the 2nd order vulnerabilities typically found in V8, these sandbox bugs could actually be prevented or mitigated by the approaches discussed earlier. In fact, the particular bug above would already be mitigated today due to Chrome's libc++ hardening
Or use Rust
I'm not saying rewrite the entire thing in Rust, too expensive & would introduce new bugs in the JIT for questionable benefit. But at least mention that & also discuss the technical challenges why the sandbox mechanism isn't written in Rust & what it would take to address those.
Look, I'm not saying the V8 team is making the wrong decisions. My questions are an indication of the shallowness of the blog write-up - why not explain some obvious questions that come up for someone who reads it?