views:

1017

answers:

4

Hello - I'm working on a hw problem that requires disabling compiler optimization protection for it to work. I'm using gcc 4.4.1 on ubuntu linux, but can't figure out which flags are are the right ones. I realize it's architecture dependant - my machine runs w/ 32-bit Intel processor.

Thanks.

A: 

Try the -fno-stack-protector flag.

Kyle Lutz
+1  A: 

I won't quote the entire page but the whole manual on optimisation is available here: http://gcc.gnu.org/onlinedocs/gcc-4.4.3/gcc/Optimize-Options.html#Optimize-Options

From the sounds of it you want at least -O0, the default, and:

-fmudflap -fmudflapth -fmudflapir

For front-ends that support it (C and C++), instrument all risky pointer/array dereferencing operations, some standard library string/heap functions, and some other associated constructs with range/validity tests. Modules so instrumented should be immune to buffer overflows, invalid heap use, and some other classes of C/C++ programming errors. The instrumentation relies on a separate runtime library (libmudflap), which will be linked into a program if -fmudflap is given at link time. Run-time behavior of the instrumented program is controlled by the MUDFLAP_OPTIONS environment variable. See env MUDFLAP_OPTIONS=-help a.out for its options.

Ninefingers
+4  A: 

That's a good problem. In order to solve that problem you will also have to disable ASLR otherwise the address of g() will be unpredictable.

Disable ASLR:

sudo echo 0 > /proc/sys/kernel/randomize_va_space

Disalbe canaries:

gcc overflow.c -o overflow -fno-stack-protector

After canaries and ASLR are disabled it should be a straight forward attack like the ones described in Smashing the Stack for Fun and Profit

Here is a list of security features used in ubuntu: https://wiki.ubuntu.com/Security/Features You don't have to worry about NX bits, the address of g() will always be in a executable region of memory because it is within the TEXT memory segment. NX bits only come into play if you are trying to execute shellcode on the stack or heap, which is not required for this assignment.

Now go and clobber that EIP!

Rook
thanks, I'll do just that :)Oh - how do I re-enable the protection to un-crap my machine?.. My guess is sudo echo 1 > /proc/sys/kernel/randomize_va_space
sa125
@sa125 yep, thats how its re-enabled. In fact thats how you switch on and off other kernel modules while the system is running ;)
Rook
+3  A: 

Urm, all of the questions so far have been wrong with Rook's answer being correct.

Disabling ASLR by:

sudo echo 0 > /proc/sys/kernel/randomize_va_space

Followed by

gcc -fno-stack-protector -z execstack -o bug bug.c

Which disables ASLR (which can be brute-forced against), SSP/Propolice and Ubuntu's NoneXec (which was placed in 9.10, and fairly simple to work around see the mprotect(2) technique to map pages as executable and jmp) should help a little, however these "security features" are by no means infallible. Without the `-z execstack' flag, pages have non-executable stack markings.

Mustapha Isyaku-Rabiu
You did not read the guys link. If you did you would know that he is trying to execute g() which is a function that is compiled into the binary. This is an address of a function. NX bits come into play when you are trying to execute shellcode on the heap or stack, his attack is far more simple.
Rook
I agree that everyone else is completely wrong, its obvious that we are the only 2 that have exploited a buffer overflow. However i still think my answer is more correct.
Rook
Hmm, just came across the link -- I thought it was just another generic, you're correct. I apologise.
Mustapha Isyaku-Rabiu
No worries man I gave you a +1 because you know whats up.
Rook