Buffer OverFlows

Buffer Overflows - Smashing the Stack

A buffer overflow occurs when you allow the user to enter more data than your program was expecting, thereby allowing arbitrary modifications to memory. Due to the way the stack is set up, an attacker can write arbitrary code into memory.

When functions are called, both the memory to store the variables declared in the function and the memory to store the arguments to the function are pushed onto the stack as part of a "stack frame".

Here is a rough picture of what the stack frame would look like for a function call:

[memory for variables in the function][FP][ret][function arguments]

First, memory is allocated for variables declared in the function. Then the frame pointer, FP, which is used to address variables within the stack frame, then the address to return to after the function call, ret, followed by the arguments to the function.

The gist of this attack is that on the stack, for every function call, the ret pointer indicates where in memory to jump once the function has finished executing. In normal execution, this should be back to the calling function. However, in some cases, if the program allows overflowing the buffer stored in the memory allocated for the function, it's possible for an attacker to set this value to point to an arbitrary region of memory into which the attacker has written executable code. (Often, this will actually be the buffer itself.)

How can a buffer overflow attack happen?

When you declare arrays in C or C++, you get a specified amount of memory to work with. This memory, on many systems, is placed before the pointer to the return site (where the function should return to after executing).

For instance, you might declare an array of 100 bytes:

char memory[100];

This is all well and good. But what if you really wanted to use 200 bytes?

C will let you:

memory[150] = 'a';

There aren't bounds checks on the array, and the code might even work. (At least in some cases, you'll get a segmentation fault, but this will depend on whether or not the memory you're accessing belongs to your program or not. You might just overwrite other data in your portion of the stack.)

But you know not to just play with memory you haven't asked for, so you probably won't do things quite like that. Generally, what happens is that a function you call will overwrite the memory instead.

You might use a function such as gets() or strcpy that isn't aware of how much memory you asked for, and consequently, how large an array you have space for. This is particularly a problem for standard library functions that work on NULL-terminated strings such as strcpy, strcat, etc. Since they rely on finding a terminating character, if the string being worked with is too long, they'll happily overwrite the end of the buffer, and if you had declared the memory as an array, you might end up overwriting data on the stack. This is what is referred to as "smashing the stack".

Other dangerous functions include scanf and sprintf for similar reasons as gets.

What should you use instead? In place of gets() or using scanf to read in a string, use fgets()

char *fgets(char *buffer, int size, FILE *stream);

fgets takes a size -- make this the size of your buffer and it will read in up to size bytes into buffer from the file pointed to by stream. So, if you want to read from standard input (stdin) in order to replace gets:

char buffer[10];
fgets(buffer, sizeof(buffer), stdin);

This will allow the user to input up to 10 bytes for use in buffer. It will, however, add a '\0' terminator to buffer. Doing so would, of course, write off the end of the array. This means that you have to add the NULL terminator manually if you want to use functions such as printf that rely on it.

Note that sizeof(buffer) works because buffer is an array; you cannot do the same thing using a char* that you dynamically allocate using malloc or new.

In place of strcpy or strcat, use the corresponding strncpy or strncat functions that take the length of data to be copied.

char *strncpy(char *destination, const char *source, size_t n);

Using strncpy will result in at most n bytes being copied from source to destination, and strncpy will return a pointer to destination. For instance, if you know that destination can hold only 20 characters:

char destination[20];
char *source = "This is a particularly long string";
strncpy(destination, source, sizeof(destination));

This will copy only as much of source as can fit in destination and return a pointer to destination. You should be aware that strncpy will not automatically append a null terminator, which means that you can go from a regular, null-terminated string to a non-null-terminated string if you try to copy a string that won't fit into the destination.

char *strncat(char *destination, const char *source, size_t n);

The strncat function copies up to n characters from source onto the end of destination, starting from the null-terminator character of destination. Again, if you run out of space in destination before reaching the end of source, you won't get a null-terminated string back. And, to replace sprintf, you can use snprintf

int snprintf(char *destination, size_t n, const char *format, ...);

which will only write a string of n bytes into the memory pointed to by destination, protecting you from an attacker's writing arbitrary data into your string when you do something like

sprintf(dest, "The user entered: %s", user_input_string);

which allows the result stored in dest to be as long as is necessary to store the user_input_string.

Although we've only looked at examples where the size of memory was allocated at compile time, and consequently ended up on the stack, similar problems apply to memory allocated during program execution. Although I don't know of a way an attacker would be able to change the flow of control by modifying memory allocated on the heap, simply by changing variables an attacker could cause problems (imagine having a username field that your program uses for access control, and that an attacker can find a way to change that memory).

Double Free Attack

Another, more sophisticated attack, is the double free attack that affects some implementations of malloc. The attack can happen when you call free on a pointer that has already been freed before you have re-initialized the pointer with a new memory address:

free(x);
/* code */
free(x);

This shouldn't ever need to happen in your code. The easiest way to avoid it is simply to set your pointer to point to NULL once you've freed it:

free(x); x = NULL;
/* code */
free(x);

Since free(NULL) is a valid operation that doesn't do anything, you're safe. Of course, this doesn't protect you from code that frees memory without telling you (or without making it obvious that memory is getting freed). One way of detecting these types of problems is to use a memory error detector such Valgrind to ensure that you only execute valid operations. (Valgrind will also detect use of initialized memory, use of invalid memory such as is the case with buffer overflows, and memory leaks.) Since the double free problem is one that should show up more or less regardless of user input -- you don't need a malicious attempt to overflow the buffer to test for double frees -- Valgrind is a good tool for finding these bugs. Of course, this isn't always the case.
This bug is harder to exploit than potential buffer overflows, and it also relies on a particular implementation of the memory allocation system. Nevertheless, it's important to ensure that your code correctly frees only valid blocks of memory.

References : http://Stackoverflow.com
http://en.wikipedia.org