A memory-safe language dramatically reduces the frequency of memory safety bugs, which are the foremost cause of security vulnerabilities in software like browsers. This is an inconvenient conclusion that everyone wants to deny, because it's, well, inconvenient. But that doesn't make it less true.
Another inconvenient conclusion that's being denied is that memory safety errors are at their core due to bad assumptions and logic errors which sadly can't be caught by compilers yet. Memory safe languages make it harder to create a specific types of vulnerabilities and can even keep them in check when they occur which is real a tangible benefit, but those same assumptions and errors will just produce different vulnerabilities.
I love Rust -- it's quickly becoming a favorite language of mine, but at some level we have to be realistic that it doesn't solve all the world's problems and evangelizing that everything be rewritten in it or another memory safe language is the programming language equivalent of saying, "you should try using machine learning."
No, because:
1. Not all such errors become vulnerabilities. An array index out of bounds exception triggered by a page causes an annoying crash in a memory safe language. In a non-memory-safe language, it is an out of bounds write that can be used to set up fun things like ROP chains.
2. Errors such as use after free simply don't exist in memory safe languages. There is no logic error that typically causes UAF: it's just straightforward failure to perform bookkeeping that a compiler and/or runtime does for you in most languages.
3. Not all vulnerabilities have the same severity. Memory safety problems tend to cause the worst of the worst: remote code execution.
Right, but we can play this game all day with different types of errors. Static typing makes improper method calling errors impossible and data hiding prevents someone from accidentally modifying internal state but we still use Python. Explicit returns makes accidental data leaking impossible but we still use Ruby. Explicit casting and comparing by value instead of identity would make all of JS's conditional errors disappear.
I completely agree with 1/3 but there are other solutions to this problem like W^X which gives similar benefits and doesn't require rewriting everything in a different language.
No, we can't "play this game all day". Those errors don't result in arbitrary code execution with anything remotely approaching the frequency that UAF does.
> I completely agree with 1/3 but there are other solutions to this problem like W^X which gives similar benefits and doesn't require rewriting everything in a different language.
W^X comes nowhere near offering similar benefits. I even specifically mentioned ROP chains to defuse that notion…
Static guarantees are particularly strong tests of whatever they guarantee, so what static guarantees the language used can provide is not an entirely separate issue from how well tested a piece of software is. (It's not the whole story, obviously, but it's a potentially important part of it.)
I don't care what it's written in. I care who is writing it and how well it is tested. Write it in Brainfuck for all I care, if it works, is efficient, and is safe.