This looks really useful. Doesn't fix the problem of memory corruption but mostly seems to limit the ability to convert that into remote code execution. And all the techniques are already in widespread use, just not the default or used together.
I would not be surprised if attackers still manage to find sneaky ways to bypass all the 4 protections, but it would certainly raise the bar significantly.
It's already been demonstrated to be insufficient; otherwise Apple software would now be impregnable. That's not to say these protections are a bad idea; they should be universal as they substantially reduce the existing attack surface - but the paper massively over-sells them as a panacea.
Most server software these days is already written in memory-safe languages yet still has security vulnerabilities. If you reduce the vulnerabilities due to memory safety issues by, say, 90%, then there's nothing special about them anymore. On the other hand, memory-safe languages also don't fully eliminate memory safety issues as they depend on operations or components that may not themselves be fully memory-safe (BTW, Rust has this problem more than other memory-safe languages).
So a "panacea" in this context doesn't mean making the stack memory-safe (which nobody does, anyway) but rather making the vulnerabilities due to memory safety no more common or dangerous than other causes of vulnerabilities (and remember that rewriting software in a new language also introduces new vulnerability risks even when it reduces others). Whether these techniques actually accomplish that or not is another matter (the paper makes empirical claims without much evidence, just as some Rust fans do).
> BTW, Rust has this problem more than other memory-safe languages
Do you have a citation there?
I've run into a ton of memory safety issues in Go because two goroutines concurrently modifying a map or pointer is a data-race, which leads to memory unsafety... and go makes it wildly easy to write such data-races. You need to manually add mutexes everywhere for go to be memory safe.
Rust, on the other hand, I've yet to run into an actual memory safety issue. Like, I'm at several hundred in Go, and 0 in rust.
Rust compiler assumes that unsafe code still follows the borrow rules and optimizes code based on that. So if that is not the case, the consequences can be bad. For example, there was a bug in Rust OpenSSL bindings where OpenSSL had not documented the proper life time of some of the function arguments/return types. As the result unsafe code containing the call to OpenSSL C implementation violated Rust memory model leading to crashes.
But I agree that such problems are rare in Rust and Go races are much more problematic.
I think the key is "as they depend on operations or components that may not themselves be fully memory-safe" indicating Rust is used a far bit more to do interop with memory unsafe languages unlike Go or Java.
I would not be surprised if attackers still manage to find sneaky ways to bypass all the 4 protections, but it would certainly raise the bar significantly.