3 ms·
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 lib
by duneroadrunner 10y ago
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 https://github.com/google/sanitizers/wiki/AddressSanitizer
- zzzcpan 10y agoIf 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/ http://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/ [2] http://sva.cs.illinois.edu/index.html http://sva.cs.illinois.edu/index.html
- duneroadrunner 10y agoYeah, 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-released https://blog.torproject.org/blog/tor-browser-55a4-hardened-r...
- the_why_of_y 10y agoWorse 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 http://seclists.org/oss-sec/2016/q1/363
- duneroadrunner 10y agoI 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.