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 in production?

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? Assume the most recent version of GCC, if you know of any cool upcoming feature, let me know!

Are you interested only in simple checks, or can they be expensive to improve detection rates? You mudflap answer suggests you don't mind paying some (significant) execution time costs. Is this for debugging, or production deployment? — Ira Baxter, Nov 24 '12 at 19:02
@Ira Baxter there is definitely a tradeoff. Assume i want the most secure binary possible, if a feature slows down runtime, let me know! I know mudflap isn't meant for production, and i left it out of the compile options. — rook, Nov 24 '12 at 19:03
What worries me about your "most secure" requirement is that you might be thinking that it's somehow possible to secure yourself against bad code with some compilation and linking tricks. Your first and foremost priority should be to have correct code! Ultimately those compiler options can only ever have a positive impact on broken code... — Kerrek SB, Nov 24 '12 at 19:14
@Kerrek SB The broken code we are talking about is Webkit, and v8. I'm need to build a very secure Linux system running open source software using the best protections available. As someone who has written buffer overflow exploits, i can tell you that these modern mitigation WORK, and work well. — rook, Nov 24 '12 at 19:23
Recently work has been going on with clang to detect several classes of runtime errors with compiler instrumentation. It has so-called 'sanitizers' to detect uninitialized memory use, buffer overflows, use-after-free, data races, and some cases of undefined behavior. Sanitizers are intended more for analysis and testing as these all have runtime performance costs, but you might want to take a look. — bames53, Nov 24 '12 at 20:24
@KerrekSB - Forgive me, but this is ridiculous. Entire classes of vulnerabilities have been exterminated by these sort of protections. You can write intentionally vulnerable code that is unexploitable on modern architectures because of things like glibc's free() and the stack protector. — zetavolt, Nov 25 '12 at 00:11
@ZephyrPellerin: You're right of course that those protections are very useful. I just wanted to make a point that they're a second line of defense and no excuse for sloppy coding, if that makes sense. — Kerrek SB, Nov 25 '12 at 12:11
@KerrekSB Conversely, I would argue that *thinking* that you are writing secure code is not a good replacement for compile time or static code analysis. I think that the answer from Ira Baxter already indicates that you may need static code analysis tools as well as gcc options. Personally I try and use checkstyle and findbugs for my Java projects, in addition to strict compiler options. Findbugs even goes as far as checking regular expressions and printf strings. Pretty usefull stuff for that alone. — Maarten Bodewes, Nov 25 '12 at 15:30
FWIW, this is a duplicate of [What is the most hardened set of options for GCC compiling C/C++?](http://security.stackexchange.com/questions/24444/what-is-the-most-hardened-set-of-options-for-gcc-compiling-c-c "What is the most hardened set of options for GCC compiling C/C++?") — ckujau, May 02 '15 at 00:13

Ira Baxter · Answer 1 · 2012-11-24T19:13:39.577

1

Not a GCC option, but compatible with GCC. See our CheckPointer tool, that detects most memory management errors.

There is a significant slowdown in execution; the tool has to track the validity of pointers and allocated storage, and that adds overhead.

edited Nov 24 '12 at 19:13

answered Nov 24 '12 at 19:05

Ira Baxter

93,541
22
172
341

Very interesting, so this is for analysis not production. Cool tools like this make me want to pick up another fuzzing project. – rook Nov 24 '12 at 19:08
I goofed. You asked for C++ options; Checkpointer doesn't (yet) do C++. I'll delete this answer if you don't ask me to retain it. – Ira Baxter Nov 24 '12 at 19:16
leave it, its still interesting. Also we are dealing with both. – rook Nov 24 '12 at 19:21

score 0 · Answer 2 · answered Apr 09 '17 at 15:24

This is not a CFLAGSor LDFLAGS answer so maybe not what you're specifically looking for but you should also look into gcc plugins written for hardening purposes. These are used in hardened kernel builds and catch a lot of bad code. You may need need a gcc plugins package for your distribution, apt-cache search gcc | grep plugin or equivalent to find the package name. I believe llvm compiler suite has similar plugins if you're willing to consider using their clang compiler (it's mostly gcc compatible)