gdb exercise!

This is a discussion on gdb exercise! within the C Programming forums, part of the General Programming Boards category; I've been looking at an exercise on buffer overflows and the stack return address. The idea is to overflow a ...

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:

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:

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).

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.

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].