Stack Smashing Protector: Difference between revisions

From OSDev.wiki
Jump to navigation Jump to search
[unchecked revision][unchecked revision]
Content added Content deleted
m (Added a link to a GCC stack protector related topic in the forum)
(→‎How to implement it: Fix the canary setter to something that works. It's now pretending to be exception-throwing code, a null terminator, and a likely invalid pointer.)
Line 62: Line 62:
/* If you have the ability to generate random numbers in your kernel then use them,
/* If you have the ability to generate random numbers in your kernel then use them,
otherwise for 32-bit code: */
otherwise for 32-bit code: */
p[0] = 0xcd; p[1] = 0x00; p[2] = 0x0a; p[3] = 0xff;
*p = 0x00000aff;
}
}



Revision as of 09:14, 5 October 2014

GCC Stack-Smashing Protector (ProPolice)

What is it?

The GCC SSP protects the stack from buffer overflows. If a buffer overflow occurs, you're informed instantly. The way this works is by inserting a "canary" value into the stack frame that, if changed, indicates a buffer overflow or stack corruption. This feature can not only detect buffer overflows, malicious or accidental, but also may help in detecting other stack-related bugs that are often found in kernel code.


How does it work?

Suppose you are writing a program to which data is passed by an external program. You may write a function like the following which accepts external data. Obviously this is a contrived example which no one would write in practice, but it demonstrates the idea.

int check_input(const char *input)
{
    char buf[16];

    strcpy(buf, input);

    // do some processing and return a value based on it
}

Now the stack frame for the above is:

Return EIP
Previous EBP
buf[12-15]
buf[8-11]
buf[4-7]
buf[0-3]

If someone passed a 24 byte value to this function as the input parameter, they could easily overwrite our return EIP and thus redirect our execution to their own malicious code. SSP is designed to protect against this. What it aims to do is insert a special value called a canary into the stack immediately after the return EIP address. On function exit, this is compared against its original value, and if it has been overwritten then execution halts with an error. It is thus able to protect against accidental and malicious buffer overflows that would affect the return address. Of note it doesn't stop one buffer overflowing into another.

The problem is that the canary value cannot be known to the person passing data to our check_input function, as otherwise they could just inject it into their data at the appropriate offset, along with an altered return EIP address, and the SSP mechanism would be none the wiser. To get around this, the gcc implementation uses a random value which is chosen fresh each time a process starts. The actual gcc implementation uses a canary value the size of a pointer and then reads the required number of bytes from /dev/urandom in the start-up code for a process. If it cannot do this, it chooses the value 0x00000aff which is at least effective protection against some attacks using the standard string copying functions (they will stop copying once they reach the null value) and most accidental overflows.


How to implement it

When you started OS developing, you might have seen that following error:

... undefined reference to __stack_chk_fail

... undefined reference to __stack_chk_guard

That's actually the SSP! You probably just didn't care about it and disabled it.

Now, implementing this feature is dead easy and it is a really handy thing.

void * __stack_chk_guard = NULL;

void __stack_chk_guard_setup()
{
    unsigned char * p;
    p = (unsigned char *) &__stack_chk_guard;

    /* If you have the ability to generate random numbers in your kernel then use them,
       otherwise for 32-bit code: */
    p[0] = 0xcd; p[1] = 0x00; p[2] = 0x0a; p[3] = 0xff;
}

void __attribute__((noreturn)) __stack_chk_fail()
{ 
    /* put your panic function or similar in here */
    unsigned char * vid = (unsigned char *)0xB8000;
    vid[1] = 7;
    for(;;)
    vid[0]++;
}

Call __stack_chk_guard_setup at early boot stage, from there on you're protected from most buffer overflows.

Don't forget to add -fstack-protector-all to the gcc flags.

See Also

Articles

Threads

External Links