2 ms·

> Binary exploitation is my field of expertise. > Creating an entire language to prevent such bugs is excessive, especially given the current state of software

> Binary exploitation is my field of expertise. > Creating an entire language to prevent such bugs is excessive, especially given the current state of software security. I'm having a hard time reconciling those 2 statements. I can imagine any 1 person having one or the other of those opinions, but not both at the same time. > Meanwhile, the vast majority of security issues (around 98%) come from basic human errors, such as reusing passwords or falling for phishing, not sophisticated zero-days exploiting memory corruption. We're not limited to doing just one thing, you know. Some people are working on improving the authentication space. Others are working on making it easier for developers to write safe code. Both of those can progress at the same time.

jdefr89 2y ago
Lcamtuf, the creator of afl shares the same opinion… I linked to his Substack in my original comment. Give that a read. My main point is over emphasis on memory safety doesn’t seem to pay off when there are lower hanging fruits on most large networks.. obviously I want memory safety, but that’s irrelevant when there are easier attack vectors still open.
- kstrauser 2y ago
  I read it. He's not saying what you seem to think he's saying. That aside, any solution that involves tooling people have to opt into is doomed to fail. We've seen this a thousand times throughout history: if you require people to go out of their convenience to choose the safer option, they won't do it. It doesn't matter how great the tools are. How cheap they are. How easy they are. If they're not part of the standard pipeline everyone gets unless they deliberately modify it, they won't be used. You've said a few times that C/C++ have tools that get you most of the same controls as Rust. First, they don't. But even if they did, those tools aren't used by default. Rust makes everyone write code that satisfies the borrow checker whether they want to or not. There's no `-Wborrow-mistakes` flag we have to set. There's not even a `-Wno-borrow-mistakes` flag we can turn off if we get tired of the error message. If you write Rust, borrows are safe, and we don't get a say in it. You can write C code that satisfies Coverity (where I use to work) and `-Wall` and Valgrind and and and, but the person next to you might not. And as long as it's easier to write unchecked C than to run it through a tester before validation, it won't be as safe as Rust at the things Rust checks. It can't be. Anything that depends on humans to make the safe choice is dead before it starts.

jdefr89 2y ago

Lcamtuf, the creator of afl shares the same opinion… I linked to his Substack in my original comment. Give that a read. My main point is over emphasis on memory safety doesn’t seem to pay off when there are lower hanging fruits on most large networks.. obviously I want memory safety, but that’s irrelevant when there are easier attack vectors still open.

kstrauser 2y ago
I read it. He's not saying what you seem to think he's saying. That aside, any solution that involves tooling people have to opt into is doomed to fail. We've seen this a thousand times throughout history: if you require people to go out of their convenience to choose the safer option, they won't do it. It doesn't matter how great the tools are. How cheap they are. How easy they are. If they're not part of the standard pipeline everyone gets unless they deliberately modify it, they won't be used. You've said a few times that C/C++ have tools that get you most of the same controls as Rust. First, they don't. But even if they did, those tools aren't used by default. Rust makes everyone write code that satisfies the borrow checker whether they want to or not. There's no `-Wborrow-mistakes` flag we have to set. There's not even a `-Wno-borrow-mistakes` flag we can turn off if we get tired of the error message. If you write Rust, borrows are safe, and we don't get a say in it. You can write C code that satisfies Coverity (where I use to work) and `-Wall` and Valgrind and and and, but the person next to you might not. And as long as it's easier to write unchecked C than to run it through a tester before validation, it won't be as safe as Rust at the things Rust checks. It can't be. Anything that depends on humans to make the safe choice is dead before it starts.