5 ms·

SaferCPlusPlus[1] is an easier option when starting from a C/C++ code base. It's also one of the faster options, but if people are willing to accept some perfor

SaferCPlusPlus[1] is an easier option when starting from a C/C++ code base. It's also one of the faster options, but if people are willing to accept some performance cost, I think the easiest solution would probably be to "harden" the LLVM/gcc sanitizers so that they can be used in deployed builds, not just debug builds. The sanitizers don't catch everything, but pretty close it seems. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus

nickpsecurity 10y ago
I'll add that SAFEcode and Softbound+CETS automatically make C programs memory-safe against lots of problems. There was also the Clay language that could've been updated. C0 is a subset that was easier to verify used in Verisoft's microkernel and apps. Rod Chapman found an error in reference implementation recoding it in SPARK Ada. So that could be used. All kinds of things could solve the C-level problems or substitute with a C wrapper but nobody cares enough to do it.
- duneroadrunner 10y ago
  SAFEcode and Softbound+CETS would be ideal, but seem to have a few problems in practice. First, the resulting executables are apparently quite slow. Like several times slower that executables compiled normally. The sanitizers are much faster, but even so the "address sanitizer" alone has a 2x performance cost. The other problem with SAFEcode and Softbound+CETS is that they don't always work. The TOR project tried to build firefox using them, but they couldn't successfully build it [1]. Perhaps nobody cared to address the C/C++ (memory) safety problems when the solutions required significant compromise. But the santizers are now (or could be with a little effort) a much more practical "no code modification required" solution than the previous options. And I think SaferCPlusPlus is now a more practical "some code modification required" solution than previous alternatives. Maybe these new and improved choices will make a difference. We can dream, can't we? :) [1] https://blog.torproject.org/category/tags/tbb-hardened https://blog.torproject.org/category/tags/tbb-hardened
  - nickpsecurity 10y ago
    "Like several times slower that executables compiled normally. " That's usually true if it's a naive scheme for safety. The main benefit of clever ones like Softbound+CETS or SAFEcode is they try to optimize away a lot of that. The first, SAFEcode paper reported worst-case of 30% overhead in their tests. SVA-OS overhead was mostly well under 2x with a few cases that did 2-4x. I can't remember what the S+C was. Remember that these also knock out almost every root cause of code injections in C apps with SVA-OS covering whole Linux kernel. Might be worth buying a second CPU to cover the overheads. ;) "The TOR project tried to build firefox using them, but they couldn't successfully build it" I wasn't aware of that. Thanks for telling me. Shows some work needs to be done. Would've been nice if they were more specific than "they didn't work." I was holding off on applying them to Tor anyway since such services must do covert-channel analyses. I'm not sure what effect these techs have on that. I recommended redoing it in SPARK Ada with Kemmerer's method for covert channel analysis. "And I think SaferCPlusPlus is now a more practical "some code modification required" solution than previous alternatives." I disagree. The reason is that there's way more tooling for statically analyzing, verifying, certifying object code of, and so on for C programs. Very little for C++ in comparison. So, taking up C++ gives you the few measures of safety it provides while forgoing tech you can get in C such as Astree Analyzer or CompCert. Too much a sacrifice. People stuck in legacy codebases might want to apply or improve on Ironclad, though. http://acg.cis.upenn.edu/papers/ironclad-oopsla.pdf http://acg.cis.upenn.edu/papers/ironclad-oopsla.pdf https://github.com/crdelozier/ironclad https://github.com/crdelozier/ironclad
    - duneroadrunner 10y ago
      Not my area of expertise, but a little googling yields: "SAFECode performance was reduced on average by a factor of 41.72 times, and the average slowdown for SoftBound was 5.36 (that is, a program runs 5.36 times slower with bounds checking than without it)." [1] As for the C versus C++ question, I don't take a position on that. The practicality of sticking with straight C (or some subset) will vary by project. SaferCPlusPlus just introduces a memory-safe subset of C++ as an option. But a subset that doesn't require the re-architecting of existing C/C++ code as it provides safe compatible substitutes for C/C++'s unsafe elements. > People stuck in legacy codebases might want to apply or improve on Ironclad, though. SaferCPlusPlus only exists because Ironclad was/is not a practical solution. In particular because Ironclad is abandonware. In my opinion, Ironclad was a brilliant and impressive solution. SaferCPlusPlus strives to be a solution in the same vein, but one that takes advantage of modern C++ in its implementation. The non-viability of Ironclad exposed key problems shared with many other approaches. Namely, portability and, more importantly, dependency risk. SaferCPlusPlus is just a simple open source library written in pure, portable C++. It works on any platform with a reasonably modern C++ compiler. If you adopt it and at some point in the future it becomes abandonware, there is no risk to your project. It will continue to build properly, and the code won't be stuck with some idiosyncratic paradigm that will interfere with future coding strategies. And the library is simple enough that it should be fairly easy to add new features or customizations as needed. [1] https://www.semanticscholar.org/paper/Performance-of-Compiler-Assisted-Memory-Safety-Showcase-Cmu/8fcdeb2e3961428a6f8ea8614f2443b61a9fb07b https://www.semanticscholar.org/paper/Performance-of-Compile...
pjmlp 10y ago
I doubt anyone in C community would turn them on anyway. They even made the "security" annex optional in C11!
- duneroadrunner 10y ago
  Well that's just it, use of the sanitizers is not up to the developers, it's a build-time option. The TOR guys have enabled them when building firefox[1]. But apparently some of their debugging features actually introduce potential vulnerabilities themselves so they're not really appropriate for deployed executables. Yet. [1] https://blog.torproject.org/category/tags/tbb-hardened https://blog.torproject.org/category/tags/tbb-hardened

nickpsecurity 10y ago

I'll add that SAFEcode and Softbound+CETS automatically make C programs memory-safe against lots of problems. There was also the Clay language that could've been updated. C0 is a subset that was easier to verify used in Verisoft's microkernel and apps. Rod Chapman found an error in reference implementation recoding it in SPARK Ada. So that could be used. All kinds of things could solve the C-level problems or substitute with a C wrapper but nobody cares enough to do it.

duneroadrunner 10y ago
SAFEcode and Softbound+CETS would be ideal, but seem to have a few problems in practice. First, the resulting executables are apparently quite slow. Like several times slower that executables compiled normally. The sanitizers are much faster, but even so the "address sanitizer" alone has a 2x performance cost. The other problem with SAFEcode and Softbound+CETS is that they don't always work. The TOR project tried to build firefox using them, but they couldn't successfully build it [1]. Perhaps nobody cared to address the C/C++ (memory) safety problems when the solutions required significant compromise. But the santizers are now (or could be with a little effort) a much more practical "no code modification required" solution than the previous options. And I think SaferCPlusPlus is now a more practical "some code modification required" solution than previous alternatives. Maybe these new and improved choices will make a difference. We can dream, can't we? :) [1] https://blog.torproject.org/category/tags/tbb-hardened https://blog.torproject.org/category/tags/tbb-hardened
- nickpsecurity 10y ago
  "Like several times slower that executables compiled normally. " That's usually true if it's a naive scheme for safety. The main benefit of clever ones like Softbound+CETS or SAFEcode is they try to optimize away a lot of that. The first, SAFEcode paper reported worst-case of 30% overhead in their tests. SVA-OS overhead was mostly well under 2x with a few cases that did 2-4x. I can't remember what the S+C was. Remember that these also knock out almost every root cause of code injections in C apps with SVA-OS covering whole Linux kernel. Might be worth buying a second CPU to cover the overheads. ;) "The TOR project tried to build firefox using them, but they couldn't successfully build it" I wasn't aware of that. Thanks for telling me. Shows some work needs to be done. Would've been nice if they were more specific than "they didn't work." I was holding off on applying them to Tor anyway since such services must do covert-channel analyses. I'm not sure what effect these techs have on that. I recommended redoing it in SPARK Ada with Kemmerer's method for covert channel analysis. "And I think SaferCPlusPlus is now a more practical "some code modification required" solution than previous alternatives." I disagree. The reason is that there's way more tooling for statically analyzing, verifying, certifying object code of, and so on for C programs. Very little for C++ in comparison. So, taking up C++ gives you the few measures of safety it provides while forgoing tech you can get in C such as Astree Analyzer or CompCert. Too much a sacrifice. People stuck in legacy codebases might want to apply or improve on Ironclad, though. http://acg.cis.upenn.edu/papers/ironclad-oopsla.pdf http://acg.cis.upenn.edu/papers/ironclad-oopsla.pdf https://github.com/crdelozier/ironclad https://github.com/crdelozier/ironclad
  - duneroadrunner 10y ago
    Not my area of expertise, but a little googling yields: "SAFECode performance was reduced on average by a factor of 41.72 times, and the average slowdown for SoftBound was 5.36 (that is, a program runs 5.36 times slower with bounds checking than without it)." [1] As for the C versus C++ question, I don't take a position on that. The practicality of sticking with straight C (or some subset) will vary by project. SaferCPlusPlus just introduces a memory-safe subset of C++ as an option. But a subset that doesn't require the re-architecting of existing C/C++ code as it provides safe compatible substitutes for C/C++'s unsafe elements. > People stuck in legacy codebases might want to apply or improve on Ironclad, though. SaferCPlusPlus only exists because Ironclad was/is not a practical solution. In particular because Ironclad is abandonware. In my opinion, Ironclad was a brilliant and impressive solution. SaferCPlusPlus strives to be a solution in the same vein, but one that takes advantage of modern C++ in its implementation. The non-viability of Ironclad exposed key problems shared with many other approaches. Namely, portability and, more importantly, dependency risk. SaferCPlusPlus is just a simple open source library written in pure, portable C++. It works on any platform with a reasonably modern C++ compiler. If you adopt it and at some point in the future it becomes abandonware, there is no risk to your project. It will continue to build properly, and the code won't be stuck with some idiosyncratic paradigm that will interfere with future coding strategies. And the library is simple enough that it should be fairly easy to add new features or customizations as needed. [1] https://www.semanticscholar.org/paper/Performance-of-Compiler-Assisted-Memory-Safety-Showcase-Cmu/8fcdeb2e3961428a6f8ea8614f2443b61a9fb07b https://www.semanticscholar.org/paper/Performance-of-Compile...

pjmlp 10y ago

I doubt anyone in C community would turn them on anyway. They even made the "security" annex optional in C11!

duneroadrunner 10y ago
Well that's just it, use of the sanitizers is not up to the developers, it's a build-time option. The TOR guys have enabled them when building firefox[1]. But apparently some of their debugging features actually introduce potential vulnerabilities themselves so they're not really appropriate for deployed executables. Yet. [1] https://blog.torproject.org/category/tags/tbb-hardened https://blog.torproject.org/category/tags/tbb-hardened