3 ms·

What features from those safer languages you want, that cannot be applied to existing OpenSSL code base? Pretty much everything they have is possible to impleme

by zzzcpan 10y ago

What features from those safer languages you want, that cannot be applied to existing OpenSSL code base? Pretty much everything they have is possible to implement for C without massive rewrites.

pjmlp 10y ago
- Bounds checking - Type safe enumerations - Strings with guaranteed size (not missing '\0') - No implicit conversions - No undefined behaviour - Validation of null pointers on access - ...
- zzzcpan 10y ago
  These all can, they just choose not to bother.
- 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 ago
    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/ 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 ago
      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-released https://blog.torproject.org/blog/tor-browser-55a4-hardened-r...
  - the_why_of_y 10y ago
    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 http://seclists.org/oss-sec/2016/q1/363
    - duneroadrunner 10y ago
      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.

by zzzcpan 10y ago

What features from those safer languages you want, that cannot be applied to existing OpenSSL code base? Pretty much everything they have is possible to implement for C without massive rewrites.

pjmlp 10y ago

- Bounds checking - Type safe enumerations - Strings with guaranteed size (not missing '\0') - No implicit conversions - No undefined behaviour - Validation of null pointers on access - ...

zzzcpan 10y ago
These all can, they just choose not to bother.
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 ago
  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/ 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 ago
    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-released https://blog.torproject.org/blog/tor-browser-55a4-hardened-r...
- the_why_of_y 10y ago
  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 http://seclists.org/oss-sec/2016/q1/363
  - duneroadrunner 10y ago
    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.