7 ms·

I feel like you're undervaluing memory safety. Memory safety prevents most (all?) exploits that lead to remote code execution. There can still be high level vul

I feel like you're undervaluing memory safety. Memory safety prevents most (all?) exploits that lead to remote code execution. There can still be high level vulnerabilities, but guaranteed memory safety is a huge improvement. Rust's type system can be used to prevent high level attacks too. For instance, if an sql library is set up properly, it can prevent sql injection by requiring inputs be properly sanitized.

steveklabnik 12y ago
I value it very highly, otherwise, I wouldn't work on Rust. :) I'm just very careful to not suggest that memory safety is the end-all, be-all of errors. The Rust compiler will help you out, but it's certainly not perfect.
- MichaelGG 12y ago
  Even if it was perfect, nothing can help you if you choose to specifically choose to share data. It was my fault for having only skimmed the original Heartbleed explanation and just made the assumption it was a memory safety issue. Sorry for making Rust look bad, especially right when y'all are working so hard on 1.0.
  - steveklabnik 12y ago
    It's all good. :) We all make mistakes. Further, I would frankly people understand that you _can_ have security bugs in Rust code, rather than think that if it compiles, there's no need to do security auditing. This post is almost a PSA of sorts. :)
munin 12y ago
this is especially incredible because the heartbleed bug was a violation of memory safety. the buffer being read from was of a size N, but you could read M bytes from it, where M > N (and in fact, MUCH greater).
tptacek 12y ago
Memory safety prevents 3 vulnerabilities that lead to remote code executions, not "most" or "all" of them. They're 3 very common and important vulnerabilities, though.
- pcwalton 12y ago
  Based on incidence in Gecko, it is indeed most of them. It depends on your project, of course.
  - tptacek 12y ago
    It's a bit tautological to suggest that fixing the most common RCE flaws in C/C++ programs by replacing the language is the same as fixing all of the most common RCE flaws. The clear point here is that memory corruption is an affliction of C/C++ programs, but that other languages have other RCE-breeding flaws.
    - MichaelGG 12y ago
      What are the other, common, RCEs? Command and SQL injection, upload and execute, etc. -- all those would apply to any language, right? Eval()/dynamic loading and little custom languages (like perhaps some "business rules" type systems) probably aren't as common in C/C++ eh? Same for overzealous serialization systems (like Ruby's YAML issues, and I think .NET's binary serialization)? What other kinds of things lead to RCE that don't or rarely occur in C/C++?
      - tptacek 12y ago
        You just hit a bunch of them. The C/C++ RCE bugs are buffer overflow (heap, stack, heap/stack via integers, &c), UAF (and double free), and uninitialized variables. It looks like there's a whole menagerie of different C/C++ RCE flaws, but they really just boil down to bounds checking, memory lifecycle, and initialization. Metacharacter bugs apply to all languages, but since Rust doesn't eliminate them --- virtually nothing does, with the possible exception of very rigorous type system programming in languages like Haskell --- the metacharacter bugs rebut the parent commenter's point. Eval() is an RCE unique to high-level dynamic languages. Taxonomically, you'd put serialization bugs here too (even the trickiest, like the Ruby Yaml thing, boil down to exposing an eval-like feature), along with the class of bugs best illustrated by PHP's RFI ("inject a reference to and sometimes upload a malicious library, then have it evaluated"). Those are just two bug metaclasses, but they describe a zillion different RCE bugs, and most of them are bugs that are not routinely discovered in C/C++ code.

steveklabnik 12y ago

I value it very highly, otherwise, I wouldn't work on Rust. :) I'm just very careful to not suggest that memory safety is the end-all, be-all of errors. The Rust compiler will help you out, but it's certainly not perfect.

MichaelGG 12y ago
Even if it was perfect, nothing can help you if you choose to specifically choose to share data. It was my fault for having only skimmed the original Heartbleed explanation and just made the assumption it was a memory safety issue. Sorry for making Rust look bad, especially right when y'all are working so hard on 1.0.
- steveklabnik 12y ago
  It's all good. :) We all make mistakes. Further, I would frankly people understand that you _can_ have security bugs in Rust code, rather than think that if it compiles, there's no need to do security auditing. This post is almost a PSA of sorts. :)

munin 12y ago

this is especially incredible because the heartbleed bug was a violation of memory safety. the buffer being read from was of a size N, but you could read M bytes from it, where M > N (and in fact, MUCH greater).

tptacek 12y ago

Memory safety prevents 3 vulnerabilities that lead to remote code executions, not "most" or "all" of them. They're 3 very common and important vulnerabilities, though.

pcwalton 12y ago
Based on incidence in Gecko, it is indeed most of them. It depends on your project, of course.
- tptacek 12y ago
  It's a bit tautological to suggest that fixing the most common RCE flaws in C/C++ programs by replacing the language is the same as fixing all of the most common RCE flaws. The clear point here is that memory corruption is an affliction of C/C++ programs, but that other languages have other RCE-breeding flaws.
  - MichaelGG 12y ago
    What are the other, common, RCEs? Command and SQL injection, upload and execute, etc. -- all those would apply to any language, right? Eval()/dynamic loading and little custom languages (like perhaps some "business rules" type systems) probably aren't as common in C/C++ eh? Same for overzealous serialization systems (like Ruby's YAML issues, and I think .NET's binary serialization)? What other kinds of things lead to RCE that don't or rarely occur in C/C++?
    - tptacek 12y ago
      You just hit a bunch of them. The C/C++ RCE bugs are buffer overflow (heap, stack, heap/stack via integers, &c), UAF (and double free), and uninitialized variables. It looks like there's a whole menagerie of different C/C++ RCE flaws, but they really just boil down to bounds checking, memory lifecycle, and initialization. Metacharacter bugs apply to all languages, but since Rust doesn't eliminate them --- virtually nothing does, with the possible exception of very rigorous type system programming in languages like Haskell --- the metacharacter bugs rebut the parent commenter's point. Eval() is an RCE unique to high-level dynamic languages. Taxonomically, you'd put serialization bugs here too (even the trickiest, like the Ruby Yaml thing, boil down to exposing an eval-like feature), along with the class of bugs best illustrated by PHP's RFI ("inject a reference to and sometimes upload a malicious library, then have it evaluated"). Those are just two bug metaclasses, but they describe a zillion different RCE bugs, and most of them are bugs that are not routinely discovered in C/C++ code.