6 ms·

> Many kinds of browser security bugs, such as the recent Heartbleed vulnerability, are prevented automatically by the Rust compiler. Does anyone care to expla

by schmrz 12y ago

> Many kinds of browser security bugs, such as the recent Heartbleed vulnerability, are prevented automatically by the Rust compiler. Does anyone care to explain how this would work? If you used OpenSSL from Rust you would still be vulnerable to Heartbleed. Or am I missing something?

jaibot 12y ago
I believe the implication is that if OpenSSL had been written in Rust, Heartbleed would not have been possible.
- joshstrange 12y ago
  Which might be true but seems odd to bring up in the blog post. Also they say: >> Many kinds of browser security bugs, such as the recent Heartbleed vulnerability, are prevented automatically by the Rust compiler. Are they referencing reverse heartbleed here? Browsers themselves were not vulnerable to heartbleed, I don't even this they were vulnerable to reverse heartbleed. There is no way Servo would have prevented the heartbleed bug, no browser could have, I feel like that sentence has no place in this blog post.
  - metajack 12y ago
    If the wording was "such as vulnerabilities similar to Heartbleed" would that make it better. The point I was trying to make is that you can't make that kind of mistake in the safe Rust language. You will fail a bounds check even if you decide to trust client provided lengths.
    - joshstrange 12y ago
      I think that would have made it better. I can believe that Rust protects you from the mistake that led to heartbleed but the statement read (to me at least) more like: "Servo protects you from that really scary thing the internet has been atwitter with for the past week whereas other browsers leave you high and dry" I know that is not what you said and probably not what you meant but it just seemed like an odd way to word IMHO.
      - metajack 12y ago
        I updated the blog post with improved wording.
  - wnevets 12y ago
    I believe its suggesting that Rust prevents the missing bounds check bug that caused heartbleed. Heartbleed is just latest example of such a bug.
  - chimeracoder 12y ago
    > Browsers themselves were not vulnerable to heartbleed, Clients could have been vulnerable to Heartbleed. Feel free to correct me on this, but I believe the only reason they weren't is that Chrome uses OpenSSL compiled without the heartbeat feature, and Firefox uses NSS.
    - azakai 12y ago
      Both Firefox and Chrome uses NSS (although I believe Chrome has a potential plan considering using OpenSSL at some point in the future).
      - gsnedders 12y ago
        Chrome on Android uses OpenSSL, FWIW. I have no idea whether it supported the Heartbeat extension though.
sanderjd 12y ago
Of course it's true that Rust can't protect you from things done in libraries called across its FFI. It's also true that at the moment most of, or at least a lot of, real work done in Rust eventually ends up calling into some C library. But I think that will be less and less true as time goes on.
- steveklabnik 12y ago
  > It's also true that at the moment most of, or at least a lot of, real work done in Rust eventually ends up calling into some C library. I'm not entirely sure this is a correct claim, unless you mean 'system calls are implemented by the kernel, which is written in C.' While it's true that FFI in Rust is really good, most things (notably, _not_ crypto) are just straight-up written in Rust.
  - sanderjd 12y ago
    That's fair, and I used the phrase "a lot of" intentionally vaguely. Yes, I'm thinking of calls into the system or common system libraries (like openssl), but also things like graphics libraries, e.g. sdl or glut. Certainly there are more pure-Rust turtles standing on one another than is the case in most languages, but the bottom turtle is still C. Edit: Servo's src/support directory is a good example of my general sense that large Rust projects still tend to rely on a good deal of C libraries: https://github.com/mozilla/servo/tree/master/src/support https://github.com/mozilla/servo/tree/master/src/support
    - pcwalton 12y ago
      Yes, and that's the primary reason why we still need to use OS sandboxing features: the Rust type system can't protect the C code that we're using, and we have to use some C code, even if it's someday just kernel32.dll. But I'm confident that the sheer number of memory-related browser vulnerabilities that have been found and continue to be found in browser engine code means that the Rust safety features are a significant security advance. It's about reducing the attack surface.
- metajack 12y ago
27182818284 12y ago
No, you're being too specific. They don't mean Heartbleed and OpenSSL, they just mean memory bugs in general. I say this because they also brought that up in the Hacker News "Who's Hiring" thread in March: "It is designed to be more memory safe (far and away the #1 cause of browser engine security bugs!)"
Ygg2 12y ago
If you wrote OpenSSL in Rust, it would avoid bugs like Heartbleed. If you called OpenSSL from Rust, it would be the same as calling C from Java. Gist of issue, Rust's static type checker would prevent bugs that caused HeartBleed.
- bjz_ 12y ago
  > Rust's static type checker would prevent bugs that caused HeartBleed I believe its more a case that it would have been a run-time error due to Rust's automatic bounds checking. This is because Rust uses 'fat pointers' for strings, vectors and slices that include bounds information rather than a single, raw pointer like in C. Do note there are unsafe ways around bounds checking, but these are restricted to unsafe blocks, which makes them easier to audit.

by schmrz 12y ago

jaibot 12y ago

I believe the implication is that if OpenSSL had been written in Rust, Heartbleed would not have been possible.

joshstrange 12y ago
Which might be true but seems odd to bring up in the blog post. Also they say: >> Many kinds of browser security bugs, such as the recent Heartbleed vulnerability, are prevented automatically by the Rust compiler. Are they referencing reverse heartbleed here? Browsers themselves were not vulnerable to heartbleed, I don't even this they were vulnerable to reverse heartbleed. There is no way Servo would have prevented the heartbleed bug, no browser could have, I feel like that sentence has no place in this blog post.
- metajack 12y ago
  If the wording was "such as vulnerabilities similar to Heartbleed" would that make it better. The point I was trying to make is that you can't make that kind of mistake in the safe Rust language. You will fail a bounds check even if you decide to trust client provided lengths.
  - joshstrange 12y ago
    I think that would have made it better. I can believe that Rust protects you from the mistake that led to heartbleed but the statement read (to me at least) more like: "Servo protects you from that really scary thing the internet has been atwitter with for the past week whereas other browsers leave you high and dry" I know that is not what you said and probably not what you meant but it just seemed like an odd way to word IMHO.
    - metajack 12y ago
      I updated the blog post with improved wording.
- wnevets 12y ago
  I believe its suggesting that Rust prevents the missing bounds check bug that caused heartbleed. Heartbleed is just latest example of such a bug.
- chimeracoder 12y ago
  > Browsers themselves were not vulnerable to heartbleed, Clients could have been vulnerable to Heartbleed. Feel free to correct me on this, but I believe the only reason they weren't is that Chrome uses OpenSSL compiled without the heartbeat feature, and Firefox uses NSS.
  - azakai 12y ago
    Both Firefox and Chrome uses NSS (although I believe Chrome has a potential plan considering using OpenSSL at some point in the future).
    - gsnedders 12y ago
      Chrome on Android uses OpenSSL, FWIW. I have no idea whether it supported the Heartbeat extension though.

sanderjd 12y ago

Of course it's true that Rust can't protect you from things done in libraries called across its FFI. It's also true that at the moment most of, or at least a lot of, real work done in Rust eventually ends up calling into some C library. But I think that will be less and less true as time goes on.

steveklabnik 12y ago
> It's also true that at the moment most of, or at least a lot of, real work done in Rust eventually ends up calling into some C library. I'm not entirely sure this is a correct claim, unless you mean 'system calls are implemented by the kernel, which is written in C.' While it's true that FFI in Rust is really good, most things (notably, _not_ crypto) are just straight-up written in Rust.
- sanderjd 12y ago
  That's fair, and I used the phrase "a lot of" intentionally vaguely. Yes, I'm thinking of calls into the system or common system libraries (like openssl), but also things like graphics libraries, e.g. sdl or glut. Certainly there are more pure-Rust turtles standing on one another than is the case in most languages, but the bottom turtle is still C. Edit: Servo's src/support directory is a good example of my general sense that large Rust projects still tend to rely on a good deal of C libraries: https://github.com/mozilla/servo/tree/master/src/support https://github.com/mozilla/servo/tree/master/src/support
  - pcwalton 12y ago
    Yes, and that's the primary reason why we still need to use OS sandboxing features: the Rust type system can't protect the C code that we're using, and we have to use some C code, even if it's someday just kernel32.dll. But I'm confident that the sheer number of memory-related browser vulnerabilities that have been found and continue to be found in browser engine code means that the Rust safety features are a significant security advance. It's about reducing the attack surface.
metajack 12y ago

27182818284 12y ago

No, you're being too specific. They don't mean Heartbleed and OpenSSL, they just mean memory bugs in general. I say this because they also brought that up in the Hacker News "Who's Hiring" thread in March: "It is designed to be more memory safe (far and away the #1 cause of browser engine security bugs!)"

Ygg2 12y ago

If you wrote OpenSSL in Rust, it would avoid bugs like Heartbleed. If you called OpenSSL from Rust, it would be the same as calling C from Java. Gist of issue, Rust's static type checker would prevent bugs that caused HeartBleed.

bjz_ 12y ago
> Rust's static type checker would prevent bugs that caused HeartBleed I believe its more a case that it would have been a run-time error due to Rust's automatic bounds checking. This is because Rust uses 'fat pointers' for strings, vectors and slices that include bounds information rather than a single, raw pointer like in C. Do note there are unsafe ways around bounds checking, but these are restricted to unsafe blocks, which makes them easier to audit.