What is the most hardened set of options for GCC compiling C/C++?

Question

What set of GCC options provide the best protection against memory corruption vulnerabilities such as Buffer Overflows, and Dangling Pointers? Does GCC provide any type of ROP chain mitigation? Are there performance concerns or other issues that would prevent this GCC option from being on a mission critical application?

I am looking at the Debian Hardening Guide as well as GCC Mudflap. Here are the following configurations I am considering:

-D_FORTIFY_SOURCE=2
-fstack-protector --param ssp-buffer-size=4
-fPIE -pie
-Wl,-z,relro,-z,now (ld -z relro and ld -z now)

Are there any improvments that can be made to this set of options?

We are most worried about protecting WebKit.

Answer 1

I don't code for gcc, so hopefully someone else can add to this, or correct me. I'll edit it with responses. Some of these will not work for all circumstances.

• -Wall -Wextra
  Turn on all warnings to help ensure the underlying code is secure.

• -Wconversion -Wsign-conversion
  Warn on unsign/sign conversion.

• -Wformat­-security
  Warn about uses of format functions that represent possible security problems.

• -Werror
  Turns all warnings into errors.

• -arch x86_64
  Compile for 64-bit to take max advantage of address space (important for ASLR; more virtual address space to chose from when randomising layout).

• -mmitigate-rop
  Attempt to compile code without unintended return addresses, making ROP just a little harder.

• -mindirect-branch=thunk -mfunction-return=thunk
  Enables retpoline (return trampolines) to mitigate some variants of Spectre V2. The second flag is necessary on Skylake+ due to the fact that the branch target buffer is vulnerable.

• -fstack-protector-all -Wstack-protector --param ssp-buffer-size=4
  Your choice of "-fstack-protector" does not protect all functions (see comments). You need -fstack-protector-all to guarantee guards are applied to all functions, although this will likely incur a performance penalty. Consider -fstack-protector-strong as a middle ground.
  The -Wstack-protector flag here gives warnings for any functions that aren't going to get protected.

• -fstack-clash-protection
  Defeats a class of attacks called stack clashing.

• -pie -fPIE
  Required to obtain the full security benefits of ASLR.

• -ftrapv
  Generates traps for signed overflow (currently bugged in gcc, and may interfere with UBSAN).

• -­D_FORTIFY_SOURCE=2
  Buffer overflow checks. See also difference between =2 and =1.

• ­-Wl,-z,relro,-z,now
  RELRO (read-only relocation). The options relro & now specified together are known as "Full RELRO". You can specify "Partial RELRO" by omitting the now flag. RELRO marks various ELF memory sections read­only (E.g. the GOT).
  

• -Wl,-z,noexecstack
  Non-executable stack. This option marks the stack non-executable, probably incompatible with a lot of code but provides a lot of security against any possible code execution. (https://www.win.tue.nl/~aeb/linux/hh/protection.html)
  
• -fvtable-verify=[std|preinit|none]
  Vtable pointer verification. It enables verification at run time, for every virtual call, that the vtable pointer through which the call is made is valid for the type of the object, and has not been corrupted or overwritten. If an invalid vtable pointer is detected at run time, an error is reported and execution of the program is immediately halted.(https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html)
  
• -fcf-protection=[full|branch|return|none]
  Enable code instrumentation of control-flow transfers to increase program security by checking that target addresses of control-flow transfer instructions (such as indirect function call, function return, indirect jump) are valid. Only available on x86(_64) with Intel's CET. (https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html)
  

If compiling on Windows, please Visual Studio instead of GCC, as some protections for Windows (ex. SEHOP) are not part of GCC, but if you must use GCC:

• -Wl,dynamicbase
  Tell linker to use ASLR protection.
• -Wl,nxcompat
  Tell linker to use DEP protection.

Answer 2

Those are good options, but you need to pay attention to your own source code. Make sure to use secure function when dealing with user inputs, filter them and when you use something like strncpy(), try not to give a lot of space to prevent certain attacks. OS itself provides security i.e. DEP (NX), ASLR and canaries to protect the stack, but you can't rely on them all the time. So, yeah, above is my suggestion. I hope that helps you a bit and you can also use source code auditing tools. Good luck!