As I learn more and more about buffer overflow exploitation 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 Internet.
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
To disable it, simply compile with the flag
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 to 2004 but I don’t think it was turned on by default originally
FORTIFY_SOURCE # 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):
Security Checking Functions ... #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
Standard 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
Protected call to strcpy 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!