ansaurus

Question

Can someone assist in explaining the backtrace output having the term 'stack smash'?

Answer 1

+6 A:

Edit: Just reread the title of your problem. You want to know why it's called a Stack Smash. When you called the function that the array was created in C generated a frame for all of your local variables, arguments to the function and the return address for the function. This frame was made on the stack and is known as a Stack Frame; sounds fair enough. This stack frame is supposed to belong to that function only and is supposed to have boundaries from the other stack frames around it; if it could change other stack frames the consequences could be dire. It would break the whole 'functions have their own scope' idea. Therefore, because your array is a local variable, it was placed in that stack frame and when you placed too much information in it you wrote just kept on writing until you reached the boundary of the stack frame, and then you kept going, C will let you do that. It sets boundaries and lets you break them at will. This going outside of the boundaries of the frame is known as 'Smashing' the stack because you ran right over other important data. Smashing the stack is destroying stack data by writing where you should not.

I should start by saying that it will not give you too much information unless you happen to know which c instructions were placed in what part of memory.

The Backtrace tells you what code was running right before that fail; namely your program which had called libc code on the array that you overflowed.

The memory map tells you which parts of memory was dedicated to what, such as where you program is, where the libraries it called are, where the heap is and where the stack is. It also gave you the permissions of those memory locations rwxp (read, write, executable, PROC_STACK) although I'm not sure about the PROC_STACK bit.

Basically, unless you know the mappings of your program in memory this is useless information. You may as well use your debugger which is much more useful. This tells you a few things:

Your program broke in libc which could mean a variety of things.
You broke the stack with your code.

I'm assuming you know that your array was initialised in the stack frame for the function that called it, and therefore, when you pushed too many values, you went out of the frame and broke the stack.

I hope that helps. If you want to know more just ask.

Robert Massaioli 2009-04-25 23:22:24

oh really thanks for reply.i knew that stack was being smashed.i wanted to know how to interpret these memory mapping and enhance the understanding of the pattern and location of the programme in the memory.please explain or provide some link to know the memory mapping of our programme.i know the heap ,data ,text and stack segment .i wanted to know how they arranged in the memory.Thanks for reply!

mawia 2009-04-26 13:30:22

Answer 2

+1 A:

It sounds like either your program or libc was built with buffer overflow protection, and you want to make sense of the data that it dumped out.

Take the address where it says your program crashed (0x804845f), subtract it from the base address of your program's .text segment (0x08048000), and look up the resulting offset in the .map file for your program.

If you don't have a .map file, edit your Makefile to pass the linker option that enables map file generation (which depends on which compiler/linker you use). Here's how to do it for GCC: -Wl,-Map,output.map.

You may also be able to look up symbol addresses using a debugger.

bk1e 2009-04-26 15:26:04

Answer 3

+1 A:

It looks like you are unable (for some reason) to post your code. So, here is some code that will trigger the same behavior. You can use this to help identify where you're going wrong in your own program:

#include <stdio.h>

/* Feel free to edit this snippet, I wrote it in a hurry and it smells
 * like feet -- Tinkertim */

int main(void)
{
        char buff[10];
        unsigned int i;
        int n;

        printf("Stack protector complains in ");

        for (i = 0, n = 10 * sizeof(buff); i < n; i++, n--) {
                buff[i] = 'c';
                printf("%d, ", n);
        }

        /* This should not be reached if the stack protector is
         * enabled */

        printf("\nLook ma, no stack protector!\n");

        return 0;
}

This sets off my stack protector (gcc / Linux) once I've tried to write to 2x the size of buff[], or 20. I have no idea how similar various stack protectors are on other systems.

What everyone has told you thus far is 100% accurate. I'm providing this answer as a supplemental, to help illustrate how it happens with a very short example.

Compile with gcc -Wall -o smash smash.c .. as you will C (pardon the pun), the language lets you break any and all rules. It will let you commit murder, but it won't let you get away with it (in most cases).

Try compiling it (again), but adding the compiler flag -fno-stack-protector to see undefined behavior caused by an overflow.

NOTES:

that does not mean disabling your stack protector is the fix for your problem :)
stack protectors don't guard against overflows, they simply protect the stack, there is a big difference between the two.

Tim Post 2009-04-26 16:14:00

ansaurus

tags:

views:

answers:

Can someone assist in explaining the backtrace output having the term 'stack smash'?

related questions