Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I'd like to try some shell codes and I want to disable linux protections.

I know I could compile using flags but I know another way exists to disable these protections in general I just can't remember. Can you help me?

share|improve this question

2 Answers 2

up vote 4 down vote accepted

Stack protection is done by the compiler (add some extra data to the stack and stash some away on call, check sanity on return). Can't disable that without recompiling. It's part of the point, really...

share|improve this answer
2  
ASLR requires the OS to do it at runtime. NX bits also require system support. What part can't be disabled at runtime? –  Jeff Ferland Mar 4 '13 at 23:38

To expand on what vonbrand has (correctly, +1) said, there are two parts to Linux's stack protection.

Stack canaries

Stack canaries are the compiler-enforced feature vonbrand refers to. These can't be disabled without a recompile.

To prove this to yourself and see how they work take the following code:

#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include <string.h>

int mybadfunction(char* a_bad_idea)
{
    char what[100];
    strcpy(what, a_bad_idea);
    printf("You passed %s\n", what);
}

int main(int argc, char** argv)
{
    printf("Tralalalaala\n");
    mybadfunction(argv[1]);
}

Now compile that (gcc -fstack-protector -masm=intel -S test.c) into something gnu as would be happy to assemble and read the output. The important point is that on exit from the mybadfunction function, there is this little piece of code:

    mov edx, DWORD PTR [ebp-12]
    xor edx, DWORD PTR gs:20
    je  .L2
    call    __stack_chk_fail

As you can guess, that's taking a stack cookie from [ebp-12] and comparing it to the value at gs:20. Doesn't match? It then calls a function __stack_chk_fail in glibc which kills your program right there.

There are ways to work around this in terms of writing exploits, but the easy way in terms of building a shellcode test case is to compile your program with -fno-stack-protector.

Non-executable pages

There are some other considerations on modern linux systems. If you take the usual shellcode testing stub:

char buffer[] = {...};

typedef void (* func)(void);

int main(int argc, char** argv)
{
    func f = (func) buffer;
    f();
    return 0;
}

modern GCC/Linux will map the .rodata section of the PE file read only with no execute permissions. You need to turn that off, which can be done using the code sample from this blog post. Basic idea: you use mprotect to add the permissions you want to the pages in which the shellcode data resides.

Non-executable stacks

If you are going to test a traditional exploit scenario, i.e. my bad code above, with your shellcode then you also need to ensure the stack is executable for the simple casse. The PE file format contains a field for determining whether the stack is executable - you can query and control this with execstack. To enable an executable stack, run

execstack -s /path/to/myprog

This can be done on arbitrary programs without needing a recompile, but won't automatically disable stack canaries as these are baked in on compile.

Added bonus: aslr:

To turn that off, echo 0 > /proc/sys/kernel/randomize_va_space.

Did you just tell someone how to exploit my precious penguin?

No. Any exploit must work around stack canaries (very much non trivial) and either find a program with execstack set, or set it (meaning it can already execute arbitrary commands anyway) or else use more difficult techniques, such as return to libc/return orientated programming.

share|improve this answer

Your Answer

 
discard

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.