OpenSSL Security Advisory - 26 Sep 2016

Re:OpenSSL Security Advisory - 26 Sep 2016 by duneroadrunner on Monday September 26, 2016 @04:06PM (#12585103)

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

[ Parent | on HN ]

Re:OpenSSL Security Advisory - 26 Sep 2016 by zzzcpan on Monday September 26, 2016 @04:41PM (#12585374)

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

[ Parent | on HN ]

Re:OpenSSL Security Advisory - 26 Sep 2016 by duneroadrunner on Tuesday September 27, 2016 @11:26AM (#12590292)

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...

[ Parent | on HN ]

Re:OpenSSL Security Advisory - 26 Sep 2016 by the_why_of_y on Monday September 26, 2016 @06:17PM (#12586080)

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

[ Parent | on HN ]

Re:OpenSSL Security Advisory - 26 Sep 2016 by duneroadrunner on Tuesday September 27, 2016 @11:14AM (#12590200)

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.

[ Parent | on HN ]