- Bounds checking

- Type safe enumerations

- Strings with guaranteed size (not missing '\0')

- No implicit conversions

- No undefined behaviour

- Validation of null pointers on access

- ...

And don't forget "use-after-free" avoidance. (Although technically "undefined behavior" covers a lot.)

Also, couldn't distros just provide a version of the library built with the AddressSanitizer[0] enabled as well? It would be slower, but should be much safer. Let the user choose? Not the ultimate solution, but for the short term.

[0] https://github.com/google/sanitizers/wiki/AddressSanitizer

If they really wanted to make memory-safe C happen, there are already SoftBound+CETS [1] and SAFECode [2] and other approaches. Rewriting all of the C libraries is just not a viable solution.

[1] http://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/

[2] http://sva.cs.illinois.edu/index.html

Yeah, apparently the Tor project considered those first but they weren't able to compile Firefox [1]. And they seem to be abandonware at this point. I didn't immediately find any indication of their performance costs.

[1] https://blog.torproject.org/blog/tor-browser-55a4-hardened-r...

Worse than the performance impact is the problem that AddressSanitizer was designed to be a debugging tool and not to mitigate exploits in production.

http://seclists.org/oss-sec/2016/q1/363

I see. Interesting that the Tor project and others had the same idea though. I wonder how feasible it would be to derive an "AddressHardener" from the AddressSanitizer.

These all can, they just choose not to bother.