Turn on memory corruption hardening where available #53
Conversation
...and leave a note that -Qunused-arguments is being applied to CFLAGS not LDFLAGS, probably in error.
Where available, enable stack smashing protection, fortify source, no-strict-overflow, and read only relocations. Many Linux distributions automatically enable most of these options. They are no brainers. The difference introduced here is in asking for a few more aggressive options. An option to disable the more aggressive options is provided (--disable-hardening). When set, configure will fall back to the default CFLAGS on the system - in many cases that will still be hardened. There is no point in going further than that. Options enabled are: -fstack-protector-strong is a relatively new GCC-4.9 feature that is supposed to give a better balance between performance and protection. -all is considered too aggressive, but was used in Chromium and other security critical systems until -strong became available. Follow their lead and use -strong when possible. clang 6.0 supports -all but not -strong. _FORTIFY_SOURCE replaces certain unsafe C str* and mem* functions with more robust equivalents when the compiler can determine the length of the buffers involved. -fno-strict-overflow instructs GCC to not make optimizations based on the assumption that signed arithmetic will wrap around on overflow (e.g. (short)0x7FFF + 1 == 0). This prevents the optimizer from doing some unexpected things. Further improvements should trap signed overflows and reduce the use of signed to refer to naturally unsigned quantities. I did not set -fPIE (position independent executables). The critical function of Open/LibreSSL is as a library, not an executable. Tested on Ubuntu Linux 14.04.1 LTS, OS X 10.10.1 with "make check". Signed-off-by: Jim Barlow <jim@purplerock.ca>
Where available, enable stack smashing protection, fortify source, no-strict-overflow, and read only relocations. Many Linux distributions automatically enable most of these options. They are no brainers. The difference introduced here is in asking for a few more aggressive options. An option to disable the more aggressive options is provided (--disable-hardening). When set, configure will fall back to the default CFLAGS on the system - in many cases that will still be hardened. There is no point in going further than that. Options enabled are: -fstack-protector-strong is a relatively new GCC-4.9 feature that is supposed to give a better balance between performance and protection. -all is considered too aggressive, but was used in Chromium and other security critical systems until -strong became available. Follow their lead and use -strong when possible. clang 6.0 supports -all but not -strong. _FORTIFY_SOURCE replaces certain unsafe C str* and mem* functions with more robust equivalents when the compiler can determine the length of the buffers involved. -fno-strict-overflow instructs GCC to not make optimizations based on the assumption that signed arithmetic will wrap around on overflow (e.g. (short)0x7FFF + 1 == 0). This prevents the optimizer from doing some unexpected things. Further improvements should trap signed overflows and reduce the use of signed to refer to naturally unsigned quantities. I did not set -fPIE (position independent executables). The critical function of Open/LibreSSL is as a library, not an executable. Tested on Ubuntu Linux 14.04.1 LTS, OS X 10.10.1 with "make check". The code added to m4/ is GPLv3 but con Signed-off-by: Jim Barlow <jim@purplerock.ca>
Conflicts: configure.ac
|
This failed on every Travis build. That's not very useful behavior. Is the claim here Ubuntu 12.04 (which Linux Travis builders are based on) and OS X do not have stack protector support? I don't think that's true. I'm not certain if this check is doing the right thing, or if the absence or presence of the compiler flag really means that stack hardening is not enabled. It's actually more ideal if the system compiler just enables it without any special flags, no? I think a lot of distributions already enable stack protector by default anyway (and you might want --fstack-protector-strong, or --fstack-protector-all) http://en.wikipedia.org/wiki/Buffer_overflow_protection#GNU_Compiler_Collection_.28GCC.29 So, who's the target for automatically setting these flags? I'm not certain its something we can judge very accurately from a compiler test. Maybe we could just update the README with some examples? |
|
Ah - all of the gcc builds got detected as clang for some reason too. In the actual clang case, wouldn't it make sense to try some of its -fsanitize options in that case as well? |
|
Some distributions don't enable stack protector. Embedded distributions are Why do this? While most distributions now enable stack protection by This works for me on Ubuntu 14.04 (GCC) and OS X 10.10.1 (Clang). The It seems that ./configure is running twice. Note that in the first pass, on On Tue, Dec 30, 2014 at 7:47 PM, Brent Cook notifications@github.com
|
|
I see it now - my addition of the scripts/ folder wasn't properly added to Makefile.am, so it didn't get through distcheck. Regarding -fsanitize, the performance penalty for some of these options is quite stiff (50% or more). As an extended test mode these options would make sense, but they may be too expensive for a release build. |
|
Thanks, I do like the results here! A few more comments: I think we need something in the scripts/wrap-compiler-for-flag-check file that explicitly says something like 'This file is in the public domain.' right at the top, based on the README here: https://github.com/kmcallister/autoharden Have you looked at what libsndfile does? https://github.com/erikd/libsndfile/tree/master/Scripts I'm not sure if some of the comments from @ToddMiller1 / @millert at http://mainisusuallyafunction.blogspot.com/2012/05/automatic-binary-hardening-with.html have been addressed. There don't seem to have been any commits to the repository since that blog post. |
|
On Thu, Jan 1, 2015 at 10:33 AM, Brent Cook notifications@github.com
Second comment is on improving the wrap-compiler-for-flag-check situation Another finding was that wrap-compiler-for-flag-check is mainly dealing —
|
|
Thanks for the explanation and for working on this. |
|
I made a couple of fixes changing the == compares to = to support systems running posix shells f2d68c7 I also found some issues building with GCC 4.2. Given the potential for other unexpected things to go haywire, I disabled the ERROR message for now in ec81c28 . We can re-enable that part later after the hardening flags have had a release for getting some field testing/feedback. |
Many compilers enable some kind of hardening by default, but this is not universally the case, and some more aggressive options are not always enabled.
There may be a performance impact to -fstack-protector-all by default, but Chromium uses this option when -fstack-protector-strong is not available, and I think that is appropriate for a critical security component.