[jp_rider]

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]

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]

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]

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]

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]

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]

Based on incidence in Gecko, it is indeed most of them. It depends on your project, of course.

[tptacek]

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]

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]

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.

[MichaelGG]

If you remove custom software like Intranet apps and focus more on products that have near ubiquitous deployment (like common desktop programs, OSes, basic server-level code), how do you think the come out? What about by number of people impacted?

[mcguire]

Right. There's an infinite number of vulnerabilities; fixing any finite number of them still leaves you with almost all vulnerabilities outstanding. But still, fixing them is good.