4 ms·

I don't think it's fair to call them dishonest here. It's pretty clear they've heard about memory safe languages, they've thought about it, they've considered i

by tux3 3y ago

I don't think it's fair to call them dishonest here. It's pretty clear they've heard about memory safe languages, they've thought about it, they've considered in details the pros and cons. >why not work on isolating it behind it’s own process (there must be ways to do this securely while not giving up too much performance)? Well, you make it sound like the easy answer. A good exercise would be to try implementing what you're proposing in a comment. Not necessarily going all the way, but enough to know why it might not be as straightforward as you think. The people working on V8 are not completely clueless, the concept of moving things out of process or using a memory safe language is not going to be a novel idea that they'll just start working on now that someone clever thought of it.

vlovich123 3y ago
The dishonest piece is that the first part talks about why Rust doesn't help with the JIT (true) but then really talks about the V8 sandbox & hardening techniques they're applying to it where Rust would help 100%. > 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?
- mandarax8 3y ago
  How would rust help you when you're executing jitted code (ie assembly)? The fizzbuzz code would run in rust but the event handler would still be unsafe jitted code.
  - rcxdude 3y ago
    It doesn't: but it helps with the stuff around it. The article talks about 3 locations for bugs 1) jitted javascript code with subtle bugs due to logic errors in the compiler (Rust's memory safety can't really help here) 2) Bugs in surrounding utility code and the interpreter (Rust can help, but running without a JIT entirely is too slow. Still, it's part of the attack surface either way) 3) Bugs in the sandbox implementation which helps mitigate bugs of the first kind (Rust can help) AFAIK the main objection raised here is the article dismisses moving to a memory safe language because it doesn't help with 1, but then discusses 2 and 3 where in fact the issues are exactly where memory safety can help.
- IainIreland 3y ago
  The whole point is that the sandbox is an approach that can be used in JIT code, where Rust doesn't help. Take the fizzbuzz example with a missing bounds check. Rust can't prevent you from generating JIT code that omits a bounds check on an array and reads/writes out-of-bounds. The sandbox doesn't prevent out-of-bounds reads/writes, but it guarantees that they will only be able to access data inside the sandbox. This means that logic bugs in the JIT compiler are no longer immediately exploitable. They must be combined with bugs in the sandbox implementation. The article's claim is that, unlike compiler bugs, sandbox bugs tend to be amenable to standard mitigation techniques. This article isn't dismissing the value of memory-safe languages. It's identifying a problem space where current memory-safe languages can't help, and providing an alternative solution. Currently, every browser JS engine is written in C++, in part because Rust doesn't solve the big correctness problems. If the sandbox approach works, then using Rust for other parts of the engine becomes more appealing.
  - vlovich123 3y ago
    To be clear. I have no issue with the sandboxing as a technique. It's perfectly valid and a good idea. My issue is that sandbox escapes are significantly easier than they should be due to the C++ runtime. Rust 100% would help mitigate sandbox escapes more effectively even as the codebase evolves. We know through lots of practical experience that "standard mitigation techniques" for C++ don't actually work all that well (there's at least about an order of magnitude difference in number of exploits possible between that & Rust).

by tux3 3y ago

vlovich123 3y ago

The dishonest piece is that the first part talks about why Rust doesn't help with the JIT (true) but then really talks about the V8 sandbox & hardening techniques they're applying to it where Rust would help 100%. > 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?

mandarax8 3y ago
How would rust help you when you're executing jitted code (ie assembly)? The fizzbuzz code would run in rust but the event handler would still be unsafe jitted code.
- rcxdude 3y ago
  It doesn't: but it helps with the stuff around it. The article talks about 3 locations for bugs 1) jitted javascript code with subtle bugs due to logic errors in the compiler (Rust's memory safety can't really help here) 2) Bugs in surrounding utility code and the interpreter (Rust can help, but running without a JIT entirely is too slow. Still, it's part of the attack surface either way) 3) Bugs in the sandbox implementation which helps mitigate bugs of the first kind (Rust can help) AFAIK the main objection raised here is the article dismisses moving to a memory safe language because it doesn't help with 1, but then discusses 2 and 3 where in fact the issues are exactly where memory safety can help.
IainIreland 3y ago
The whole point is that the sandbox is an approach that can be used in JIT code, where Rust doesn't help. Take the fizzbuzz example with a missing bounds check. Rust can't prevent you from generating JIT code that omits a bounds check on an array and reads/writes out-of-bounds. The sandbox doesn't prevent out-of-bounds reads/writes, but it guarantees that they will only be able to access data inside the sandbox. This means that logic bugs in the JIT compiler are no longer immediately exploitable. They must be combined with bugs in the sandbox implementation. The article's claim is that, unlike compiler bugs, sandbox bugs tend to be amenable to standard mitigation techniques. This article isn't dismissing the value of memory-safe languages. It's identifying a problem space where current memory-safe languages can't help, and providing an alternative solution. Currently, every browser JS engine is written in C++, in part because Rust doesn't solve the big correctness problems. If the sandbox approach works, then using Rust for other parts of the engine becomes more appealing.
- vlovich123 3y ago
  To be clear. I have no issue with the sandboxing as a technique. It's perfectly valid and a good idea. My issue is that sandbox escapes are significantly easier than they should be due to the C++ runtime. Rust 100% would help mitigate sandbox escapes more effectively even as the codebase evolves. We know through lots of practical experience that "standard mitigation techniques" for C++ don't actually work all that well (there's at least about an order of magnitude difference in number of exploits possible between that & Rust).