[schmrz]

> 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]

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

[joshstrange]

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]

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]

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]

I updated the blog post with improved wording.

[wnevets]

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]

> 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]

Both Firefox and Chrome uses NSS (although I believe Chrome has a potential plan considering using OpenSSL at some point in the future).

[gsnedders]

Chrome on Android uses OpenSSL, FWIW. I have no idea whether it supported the Heartbeat extension though.

[Ygg2]

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_]

> 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.

[27182818284]

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!)"

[sanderjd]

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.

[metajack]

Lots of bits of Servo use the FFI, but we've been replacing them as we go along with Rust versions. We did this so we could stand up a whole browser as fast as possible and then iterate on the important pieces first.

As an example, we used to use Netsurf's C library for CSS stuff, but now we have our own parser and style system written in 100% Rust.

[sanderjd]

I think it's a great approach, and I plan to whole-heartedly enjoy watching more and more of those chunks get whittled away as time goes on. I'd love to see a pure-rust spidermonkey replacement at some point!

[steveklabnik]

> 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]

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

[pcwalton]

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.