4 ms·

It’s interesting that it spends a lot of time talking about how memory safe languages don’t help V8 cause of JIT (true) & then talks about a hardening technique

It’s interesting that it spends a lot of time talking about how memory safe languages don’t help V8 cause of JIT (true) & then talks about a hardening technique that does get helped by Rust. Why not just be honest and say that the switching cost to a new language is too expensive and error prone than play these games? Similarly the discussion about memory tagging - I know that it would harden the security of things like Cloudflare workers. And if most of the exploits are because it’s in-process, 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)?

olliej 3y ago
…because the overwhelming majority of memory safety bugs in js engines (v8, JSC, and spider monkey) are in operations that would be in unsafe blocks in rust as well? In multiple decades I can think of a handful of engine bugs that would have been prevented by rust - and those were largely preventable (and now are) in c++ as well. It is possible for rust to be a safer language than c++ and to also not meaningfully change the security profile of the language. It’s not just the jit, the interpreter and GCs are also subject largely - necessarily - no more protected by rust than c++.
- vlovich123 3y ago
  Did you read the article? It has nothing to do with the JIT. It uses the JIT as a smokescreen to talk about sandbox hardening & the issues within the sandbox are definitely not "unsafe" & 100% mitigated by Rust. Take a look at the relevant quotes I extracted in another comment to draw your attention to what the article is actually talking about (sandbox hardening).
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.
wavemode 3y ago
> talks about a hardening technique that does get helped by Rust What hardening technique discussed in this article would be helped by Rust, and what specific feature of Rust would help?
- vlovich123 3y ago
  > This code makes the (reasonable) assumption that the number of properties stored directly in a JSObject must be less than the total number of properties of that object. 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. > 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. 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. As such, the hope is that in the long run, the sandbox becomes a more defensible security boundary than V8 itself
  - wavemode 3y ago
    It's still not clear to me what Rust feature would prevent what specific vulnerability here. Rust has bounds-checked and non-bounds-checked array accesses depending on the developer's preference, and so does C++. If there's some point you're making with these quotes you're going to need to simplify it for me since I'm not following.
    - rcxdude 3y ago
      The defaults are switched though: C++ is unchecked by default, Rust is checked by default.
    - tubthumper8 3y ago
      > Rust has bounds-checked and non-bounds-checked array accesses depending on the developer's preference, and so does C++ You're making it sound like these are the same, the difference is the defaults Unsafely accessing an element in C++ vec[i] Unsafely accessing an element in Rust unsafe { vec.get_unchecked(i) } One of these is screamingly obvious that something potentially unsafe is happening and should be audited more closely, that's the real difference. The cause of potential memory issues is isolated and searchable in `unsafe` blocks rather than being potentially anywhere
CodeNest 3y ago
[dead]
azakai 3y ago
The technique here keeps a large set of objects from escaping the sandbox. Those objects are accessed both by C++ and JIT code. You are right that using Rust instead of C++ would help on the C++ side, but it would not help at all on the JIT code side, and that is by far the major source of exploits. In other words, even if you write a JS engine in Rust you could benefit greatly from this technique.
- vlovich123 3y ago
  I have no issue with the sandbox technique. My critique is that the sandbox escapes just have to find an assumption violation in C++ that leads to a memory violation, meaning that sandbox escapes are easier in V8 due to being written in C++. Having the sandbox & security-relevant runtime pieces written in Rust would do a lot to prevent huge swathes of sandbox escapes more robustly than trying to ensure that all C++ today & that will be written remains hardened.

olliej 3y ago

…because the overwhelming majority of memory safety bugs in js engines (v8, JSC, and spider monkey) are in operations that would be in unsafe blocks in rust as well? In multiple decades I can think of a handful of engine bugs that would have been prevented by rust - and those were largely preventable (and now are) in c++ as well. It is possible for rust to be a safer language than c++ and to also not meaningfully change the security profile of the language. It’s not just the jit, the interpreter and GCs are also subject largely - necessarily - no more protected by rust than c++.

vlovich123 3y ago
Did you read the article? It has nothing to do with the JIT. It uses the JIT as a smokescreen to talk about sandbox hardening & the issues within the sandbox are definitely not "unsafe" & 100% mitigated by Rust. Take a look at the relevant quotes I extracted in another comment to draw your attention to what the article is actually talking about (sandbox hardening).

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.

wavemode 3y ago

> talks about a hardening technique that does get helped by Rust What hardening technique discussed in this article would be helped by Rust, and what specific feature of Rust would help?

vlovich123 3y ago
> This code makes the (reasonable) assumption that the number of properties stored directly in a JSObject must be less than the total number of properties of that object. 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. > 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. 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. As such, the hope is that in the long run, the sandbox becomes a more defensible security boundary than V8 itself
- wavemode 3y ago
  It's still not clear to me what Rust feature would prevent what specific vulnerability here. Rust has bounds-checked and non-bounds-checked array accesses depending on the developer's preference, and so does C++. If there's some point you're making with these quotes you're going to need to simplify it for me since I'm not following.
  - rcxdude 3y ago
    The defaults are switched though: C++ is unchecked by default, Rust is checked by default.
  - tubthumper8 3y ago
    > Rust has bounds-checked and non-bounds-checked array accesses depending on the developer's preference, and so does C++ You're making it sound like these are the same, the difference is the defaults Unsafely accessing an element in C++ vec[i] Unsafely accessing an element in Rust unsafe { vec.get_unchecked(i) } One of these is screamingly obvious that something potentially unsafe is happening and should be audited more closely, that's the real difference. The cause of potential memory issues is isolated and searchable in `unsafe` blocks rather than being potentially anywhere

CodeNest 3y ago

[dead]

azakai 3y ago

The technique here keeps a large set of objects from escaping the sandbox. Those objects are accessed both by C++ and JIT code. You are right that using Rust instead of C++ would help on the C++ side, but it would not help at all on the JIT code side, and that is by far the major source of exploits. In other words, even if you write a JS engine in Rust you could benefit greatly from this technique.

vlovich123 3y ago
I have no issue with the sandbox technique. My critique is that the sandbox escapes just have to find an assumption violation in C++ that leads to a memory violation, meaning that sandbox escapes are easier in V8 due to being written in C++. Having the sandbox & security-relevant runtime pieces written in Rust would do a lot to prevent huge swathes of sandbox escapes more robustly than trying to ensure that all C++ today & that will be written remains hardened.