Spread the love

As I’m learning more and more about exploiting buffer overflows I’m realizing that it’s actually pretty hard to run the examples that teach you how to exploit buffer overflows. GCC (and other compilers) have built in support for mitigating the simple buffer overflows and it’s turned on by default.

With GCC you have to compile with the -fno-stack-protector option otherwise you get “***stack smashing detected***,” this is pretty well known and documented all over the net.

However, additionally you’ll need to disable the FORTIFY_SOURCE option otherwise you’ll get “Abort trap” if you try to do a buffer overflow that uses something like strcpy or memcpy.

To disable it, simply compile with the flag -D_FORTIFY_SOURCE=0 (e.g. gcc -g -fno-stack-protector -D_FORTIFY_SOURCE=0 -o overflow_example overflow_example.c)

FORTIFY_SOURCE is enabled by default on a lot of Unix like OSes today. It’s original development dates back almost 6 years ago but I don’t think it was turned on by default until recently (within the past 2 years)

#  else
#    define _FORTIFY_SOURCE 2	/* on by default */
#  endif

That means that when you include something like “string.h”, at the bottom of “string.h” is the following (at least on Mac OS X 10.6):

...
#if defined (__GNUC__) && _FORTIFY_SOURCE > 0 && !defined (__cplusplus)
/* Security checking functions.  */
#include <secure/_string.h>
#endif

So when you compile, instead of seeing a call to strcpy

0x0000000100000d50 <main+188>:  lea    rdi,[rbp-0x20]
0x0000000100000d54 <main+192>:  call   0x100000dba <dyld_stub_strcpy>
0x0000000100000d59 <main+197>:  lea    rdx,[rbp-0x20]

you’ll see a call to the strcpy_chk function in your disassembled code

0x0000000100000d50 <main+192>:  mov    edx,0x8
0x0000000100000d55 <main+197>:  call   0x100000daa <dyld_stub___strcpy_chk>
0x0000000100000d5a <main+202>:  lea    rdx,[rbp-0x20]

This will wreck havoc on any of your simple buffer overflow exploiting examples so make sure you disable it when you compile. Happy exploiting!