Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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:

-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.

share|improve this question
gcc -x ada. Seriously, if you don't want exploitable programs, start by using a programming language that doesn't go out of its way to let programmers write exploitable code. – Gilles Nov 25 '12 at 19:28
@Gilles cool let me know when they write a browser in ada. – rook Nov 25 '12 at 19:38
There was a Web browser written in Objective Caml, but the project has stalled more than ten years ago (thus not usable in practice): – Thomas Pornin Nov 29 '12 at 16:43
There is also Lobo which is more recent, and in Java. – Thomas Pornin Nov 29 '12 at 16:46
The mozilla community is working on a Browser Engine written in Rust, that should provide a much better security level than C. (Although, I admit I cannot compare it to ADA, as I don't know anything about ADA.) – MarkusSchaber Jun 4 at 17:38
up vote 28 down vote accepted

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).

  • -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.

  • -pie -fPIE
    For ASLR

  • -ftrapv
    Generates traps for signed overflow (currently bugged in gcc)

    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)

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
share|improve this answer
enabling warnings doesn't help prevent the compromise of a running system. Also, without -fstack-protector-all canary's are only added to functions that may incur a stack based overflow that contain an array larger than 4 bytes (as per ssp-buffer-size=4 ). Not every function needs to be protected by a canary, that is just a waste. Also I am on a 32bit system... So this post hasn't changed my build options. – rook Dec 2 '12 at 19:39
@Rook He's using -Werror, so the warnings become errors. He can't compile it, unless he's fixing the source. – sfx Dec 3 '12 at 18:38
@sfx "he" is me, and "the source" is webkit. – rook Dec 3 '12 at 18:39
Well maybe add some information about glibc 2.5 protections and anything else you can think of, and I'll awarded it. – rook Dec 5 '12 at 20:29
@RJFalconer Compiling as X86_64 gives the application a lot more virtual address space. The ASLR is then more effective, since there is more addresses to choose from when randomizing. – user7610 Apr 25 '14 at 20:33

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!

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.