I mean, I don't disagree, but it probably would not have helped in this case.
This is based on a buffer overflow in glibc itself. It is my understanding that rust still calls into libc for many lowlevel system functions. And if you call C code from rust, well, it's still C code with C code bugs.
Ultimately, if you want to get rid of those, you'd have to rewrite the libc in Rust.
> Ultimately, if you want to get rid of those, you'd have to rewrite the libc in Rust.
No, you can eliminate these bugs by getting better at writing code. The language is independent from the quality of any given code.
Rust is capable of introducing theses bugs, but the language is more explicit when you do. One languages isn't more secure than another. They each attempt to fill a niche, some trade language usability for correctness, some trade correctness for being easy to use.
Alex isn't that convincing. And what data? Are you counting his opinion as data?
Actually asking: Are there any studies that show high quality code is just as memory unsafe as low quality code?
Are there any studies that show excluding memory overrun bugs, rust code has a lower risk of being exploitable?
What about a memory unsafe language like C written to the MISRA C standards?
I'll happily admit I'm just an old dude angry on the Internet... doesn't mean I'm wrong :)
In the presentation there are links to multiple companies observing a consistent 60-70% of high severity security issues being attributed to memory safety issues. These are companies that are organized, well resourced, etc.
Additionally, even in brilliant soloist projects like curl, Linux, etc., you still get plenty of memory safety CVEs. The best still don't get it right.
> Are there any studies that show excluding memory overrun bugs...
Why exclude memory safety from the argument? That's the whole point -- to fix those significant fraction of vulnerabilities.
> Why exclude memory safety from the argument? That's the whole point -- to fix those significant fraction of vulnerabilities.
Because while it's a significant fraction of those vulnerabilities found. (key worksd found, because they're easier to find) It's not a significant fraction of the vulnerabilities leading to exploitation.
My original argument was, security issues are preventable by increasing skill. You tried to claim that's merely an instinctual reaction of anger. My refutation is that, yes rust eliminates some memory safety issues, when used correctly, and when you limit yourself to a smaller subset of the language.
The two arguments, 1 isn't that also true for MIRSA C, and 2 does programming is rust lead to a lower defect count in any other metric than memory safety?
Because if exploitation isn't due to memory safety, fixing that class of bug doesn't improve security.
And I'll actually make a 3rd argument, Does a large rust project have a lower defect density than a solo project written by an expert, like you e.g. curl?
>researching what tactics are effective at convincing developers to reconsider C and C++
So he says nothing about how to write better code, but how to convince developers to do it? It's known how to write better code at fairly low effort and is used in several popular projects, mostly networking for obvious reasons.
This is based on a buffer overflow in glibc itself. It is my understanding that rust still calls into libc for many lowlevel system functions. And if you call C code from rust, well, it's still C code with C code bugs.
Ultimately, if you want to get rid of those, you'd have to rewrite the libc in Rust.