CODEWITHSUNDEEP
clinuxstack-overflow
JACK M
JACK M

Reputation: 2851

My overflow code does not work

The code below is from the well-known article Smashing The Stack For Fun And Profit.

void function(int a, int b, int c) {
  char buffer1[5];
  char buffer2[10];
  int *ret;
  ret = buffer1 + 12;
  (*ret)+=8;
}

void main() {
  int x;
  x=0;
  function(1,2,3);
  x=1;
  printf("%d\n",x);
}

I think I must explain my target of this code. The stack model is below. The number below the word is the number of bytes of the variable in the stack. So, if I want to rewrite RET to skip the statement I want, I calculate the offset from buffer1 to RET is 8+4=12. Since the architecture is x86 Linux.

buffer2 buffer1 BSP RET   a    b    c
(12)    (8)     (4) (4)   (4)  (4)  (4)

I want to skip the statement x=1; and let printf() output 0 on the screen.

I compile the code with:

gcc  stack2.c  -g

and run it in gdb:

gdb ./a.out

gdb gives me the result like this:

Program received signal SIGSEGV, Segmentation fault.
main () at stack2.c:17
17  x = 1;

I think Linux uses some mechanism to protect against stack overflow. Maybe Linux stores the RET address in another place and compares the RET address in the stack before functions return.

And what is the detail about the mechanism? How should I rewrite the code to make the program output 0?

OK,the disassemble code is below.It comes form the output of gdb since I think is more easy to read for you.And anybody can tell me how to paste a long code sequence?Copy and paste one by one makes me too tired...

Dump of assembler code for function main:
0x08048402 <+0>:    push   %ebp
0x08048403 <+1>:    mov    %esp,%ebp
0x08048405 <+3>:    sub    $0x10,%esp
0x08048408 <+6>:    movl   $0x0,-0x4(%ebp)
0x0804840f <+13>:   movl   $0x3,0x8(%esp)
0x08048417 <+21>:   movl   $0x2,0x4(%esp)
0x0804841f <+29>:   movl   $0x1,(%esp)
0x08048426 <+36>:   call   0x80483e4 <function>
0x0804842b <+41>:   movl   $0x1,-0x4(%ebp)
0x08048432 <+48>:   mov    $0x8048520,%eax
0x08048437 <+53>:   mov    -0x4(%ebp),%edx
0x0804843a <+56>:   mov    %edx,0x4(%esp)
0x0804843e <+60>:   mov    %eax,(%esp)
0x08048441 <+63>:   call   0x804831c <printf@plt>
0x08048446 <+68>:   mov    $0x0,%eax
0x0804844b <+73>:   leave
0x0804844c <+74>:   ret


Dump of assembler code for function function:
0x080483e4 <+0>:    push   %ebp
0x080483e5 <+1>:    mov    %esp,%ebp
0x080483e7 <+3>:    sub    $0x14,%esp
0x080483ea <+6>:    lea    -0x9(%ebp),%eax
0x080483ed <+9>:    add    $0x3,%eax
0x080483f0 <+12>:   mov    %eax,-0x4(%ebp)
0x080483f3 <+15>:   mov    -0x4(%ebp),%eax
0x080483f6 <+18>:   mov    (%eax),%eax
0x080483f8 <+20>:   lea    0x8(%eax),%edx
0x080483fb <+23>:   mov    -0x4(%ebp),%eax
0x080483fe <+26>:   mov    %edx,(%eax)
0x08048400 <+28>:   leave
0x08048401 <+29>:   ret

I check the assemble code and find some mistake about my program,and I have rewrite (*ret)+=8 to (*ret)+=7,since 0x08048432 <+48>minus0x0804842b <+41> is 7.

Upvotes: 2

Views: 364

Answers (3)

fdk1342
fdk1342

Reputation: 3564

Because that article is from 1996 and the assumptions are incorrect.

Refer to "Smashing The Modern Stack For Fun And Profit"

http://www.ethicalhacker.net/content/view/122/24/

From the above link:

However, the GNU C Compiler (gcc) has evolved since 1998, and as a result, many people are left wondering why they can't get the examples to work for them, or if they do get the code to work, why they had to make the changes that they did.

Upvotes: 2

Aaron Digulla
Aaron Digulla

Reputation: 328760

Try ret = buffer1 + 3;

Explanation: ret is an integer pointer; incrementing it by 1 adds 4 bytes to the address on 32bit machines.

Upvotes: 0

Some programmer dude
Some programmer dude

Reputation: 409404

The function function overwrites some place of the stack outside of its own, which is this case is the stack of main. What it overwrites I don't know, but it causes the segmentation fault you see. It might be some protection employed by the operating system, but it might as well be the generated code just does something wrong when wrong value is at that position on the stack.

This is a really good example of what may happen when you write outside of your allocated memory. It might crash directly, it might crash somewhere completely different, or if might not crash at all but instead just do some calculation wrong.

Upvotes: 0

Related Questions