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



Question:

plz explain the follwing result of the stack smash after running a programming in which input i gave is much more than the capacity of the charachter array.

    *** stack smashing detected ***: ./a.out terminated               ======= Backtrace: =========  /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7f856d8]  /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x0)[0xb7f85690]  ./a.out[0x804845f]      [0x666a6473]  ======= Memory map: ========  08048000-08049000 r-xp 00000000 08:07 91312      /home/mawia/a.out  08049000-0804a000 r--p 00000000 08:07 91312      /home/mawia/a.out   0804a000-0804b000 rw-p 00001000 08:07 91312      /home/mawia/a.out  084cd000-084ee000 rw-p 084cd000 00:00 0          [heap]  b7e6d000-b7e7a000 r-xp 00000000 08:07 221205     /lib/libgcc_s.so.1  b7e7a000-b7e7b000 r--p 0000c000 08:07 221205     /lib/libgcc_s.so.1  b7e7b000-b7e7c000 rw-p 0000d000 08:07 221205     /lib/libgcc_s.so.1  b7e8a000-b7e8b000 rw-p b7e8a000 00:00 0   b7e8b000-b7fe3000 r-xp 00000000 08:07 238955     /lib/tls/i686/cmov/libc-2.8.90.so  b7fe3000-b7fe5000 r--p 00158000 08:07 238955     /lib/tls/i686/cmov/libc-2.8.90.so  b7fe5000-b7fe6000 rw-p 0015a000 08:07 238955     /lib/tls/i686/cmov/libc-2.8.90.so  b7fe6000-b7fe9000 rw-p b7fe6000 00:00 0   b7ff6000-b7ff9000 rw-p b7ff6000 00:00 0   b7ff9000-b8013000 r-xp 00000000 08:07 221196     /lib/ld-2.8.90.so  b8013000-b8014000 r-xp b8013000 00:00 0          [vdso]  b8014000-b8015000 r--p 0001a000 08:07 221196     /lib/ld-2.8.90.so  b8015000-b8016000 rw-p 0001b000 08:07 221196     /lib/ld-2.8.90.so  bfd00000-bfd15000 rw-p bffeb000 00:00 0          [stack]  Aborted  

please explain the detail of the following memory map and significance of the various detail given in this report.

EDIT:

the code is simply to input a string.I intentionally input the string whose size was larger than the lenth of the charachter array i had defined to produce a stack smash. code:

 int main()     {    int a;    char s[10];    scanf("%s",s);    return 0;   }  

Thanks.


Solution:1

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:

  1. Your program broke in libc which could mean a variety of things.
  2. 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.


Solution:2

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.


Solution:3

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.

Note:If u also have question or solution just comment us below or mail us on toontricks1994@gmail.com
Previous
Next Post »