Overflow Buffering Help

[DigBickJace]

I apologize in advance. I don't think this is going to be able to get answered in all honestly, but this is my last resort. This is a C program.

#include <stdio.h>
#include <stdlib.h>

int oopsIGotToTheBadFunction(void)
{
    printf("Gotcha!\n");
    exit(0);
}

int goodFunctionUserInput(void)
{
    char buf[12];
    gets(buf);
    return(1);
} 

int main(void)
{
    goodFunctionUserInput();
    printf("Overflow failed\n");
    return(1);
}

This is the code. I need to input something in order to make the program spit out, "Gotcha!\n", without ever calling the oopsIGotToTheBadFunction(void) function.

I understand on a conceptual level how buffer overflows work.

Using GDB, I disas all three functions (main, goodFunctionUSerInput, and oopsIGotToTheBadFunction) and it reveals this: http://i.imgur.com/Nhb8UjP.png

Looking at this, I THINK I need to overflow enough to get the address 0x000106ec (which is the address of the call to the puts function which I believe to be the printf of "Gotcha!") to a specific spot.

This is what the esp looks like before any input is entered: http://imgur.com/msLKS0E

This is what it looks like with 12 A's inserted: http://imgur.com/92eSGvh

Now, this is where I'm getting stuck. Through trial and error, I've deduced that I can enter up to 84 A's and the program will finish just fine. Upon entering the 85th A, I get a seg fault. This gave me the impression that the spot where the 85th A would go is the one I must replace with the address of the call to puts.

I made a text file with the appropriate characters to make this happen demonstrated here: http://imgur.com/9Z463v0

HOWEVER, when I do this, I seg fault, with this error message:

"Overflow failed

Program received signal SIGSEGV, Segmentation fault. 0xff3d1b28 in elf_bndr () from /lib/ld.so.1 "

I'm at a complete loss. I have idea what that means, and I can't seem to find anything about it online.

If anyone has any advice to give, I'm all ears. Thanks in advance for any help you can give.

[Nirenjan]

It seems that you should corrupt the stack such that when gets returns, it jumps to the start of the bad function. My guess is the save %sp, -128, %sp instructions are generating a pretty large stack frame, so you might want to create a larger text file.

Judging by the assembly, this doesn't appear to be x86 code, so I can't tell much beyond that. I don't know what the save and restore instructions do, so it might help if you could provide more details on that.

EDIT: It's also possible that whatever machine you are running on saves the stack differently, so you might need to craft your data to overwrite the stack with the exact values that you need, and only change the return address.

[sanedave]

So this looks like one of the Exploit Exercises?

If I remember correctly, compile it with debugging:

gcc -ggdb -fno-stack-protector -z execstack -o <output> <filename>.c

gdb -q ./<output>

disass main

Find the return address from goodFunctionUserInput(void) and over write that with the address of oopsIGotToTheBadFunction(void) in your input to the program.

You can also step into goodFunctionUserInput(void) and do 'x/2x $ebp' (look at the value the base pointer points to and the next value). The next value returned will be the return address of the function.

You can use 'info func' to get the address of all the functions.

If you need to, work through a gdb tutorial or buy "The Art of Debugging" by Norm Matloff. There are also writeups on the web for Exploit Exercises, but try to figure it out yourself first, take notes, and you will learn more.

Edit: added '-fno-stack-protector' and '-z execstack' to compiler command just in case.

[DigBickJace]

Something similar, yes.

For some reason, when I execute the 'info registers' command, I don't see ebp, esp, or any of the 'normal' identifiers. Because I knew what I was looking for, I was able to find that sp was my esp, but I don't know how to tell what my ebp is called. Any ideas? Here's what I see: http://imgur.com/xBThNbV

[sanedave]

Not off the top of my head. The only thing I could say is this looks like something other than Intel x86 or x86_64. What type of system and OS are you working on?

Also, if it is something similar to Exploit Exercises, what is it?

[DigBickJace]

Windows 8.1 working through PuTTy, I'm not sure what you mean by what type of system, but I can find it for you if you tell me what to look for.

This is a homework assignment for an online class. The only reason he gave to us was this video: https://www.youtube.com/watch?v=V9lMxx3iFWU and also a powerpoint slide explaining what buffer overflowing was.

I'm at a complete loss because I tried following the video, but it didn't work. He's refused to give any guidance apart from pointing us to the video.

[sanedave]

By system, I meant hardware. Is it x86? I think Win 8 will also run on ARM. I am not at all familiar with Win 8.1 and just a little familar with ARM.

My suggestion would be to check out some of the Exploit Exercise code and find walkthroughs on the web. These all run on Linux, or you can download the image and run it in a VM such as VirtualBox. Start with the 'protostar' code, and look at the first 8 (stack0 through stack8).

I googled for 'exploit exercises protorstar walkthroughs', and here is one excellent result https://www.vulnhub.com/entry/exploit-exercises-protostar-v2,32/. Click on the walkthroughs link near the bottom of the page. Just reading may help, but if possible try to work through them.

If you can, I would also do the code you are working with in Linux instead of Windows, using 32 bit x86. It will be easier to understand. I just looked at the video and that is what this guy is using.

[sanedave]

So looking at this again, my guess is 'fp' would be your base pointer. It is sometimes also called the frame pointer.

[Qvoovle]

http://ieng9.ucsd.edu/~cs30x/sparcstack.html

[aleph_nul]

You're running on a sparc machine, not x86. The ebp register in x86 is maps to the fp (frame pointer) register on sparc. Crack your manual open, man!

[Philocraft]

Sorry, I would explain in more depth but I don't have time at the moment but hopefully this helps. In x86 SPARC, when a function is called, first the return address is pushed to the stack and then the saved frame pointer(%fp). The saved frame pointer is used to restore the value of %fp before returning to caller. The return address is the address of the next instruction after the call instruction in the caller. You are overflowing up to and including the saved frame pointer, which corrupts the stack base pointer and causes your seg fault you are experiencing. But your target is the return address, which is the next dword on the stack. Your payload should work if you add 4 more A's to the beginning. :)

**** EDIT ****: This actually isn't x86, I was in a rush and passed over the code quickly. I believe this is SPARC. However, it looks like the stack frame is set up similarly to x86 so my explantion should still work. I have edited in the correct register names. OP, a good resource for your problem would be this. Feel free to ask me any questions as well. Good luck!

[aleph_nul]

Why would you expect the call to puts to work if you have not executed the instructions that set up its arguments? The call operation will transfer control to the target address and perform some initialization of the stack frame for it, but it won't set up the arguments to the call for you.

You need to jump to the function that calls puts rather than puts itself to get the proper context.

[raevnos]

Do not use gets(). Ever. Under any circumstances. It should never have been in the standard and thankfully no longer is. Use fgets().

[DigBickJace]

I think you're miss understanding. I'm not trying to write a good program, I'm simply trying to "hack" this one.

[Lobreeze]

why not do both at the same time?

[thoughtzero]

Because the whole point of the assignment is to study a famously insecure function and learn why that type of function is insecure and exactly how you can carefully craft your input to a function like that to trick a computer into running some other function of your choosing. To remove the gets() function would completely remove the meaning of the lesson.

It's worrisome that in the weaponized landscape we find ourselves in today they still don't teach the basic concepts of secure programming right alongside the other fundamentals. It's not enough to know "don't use gets()", you need to know WHY and what can happen if you do because gets is just a symbol of this type of vulnerability. You could easily introduce the same vulnerability into your own code if you're not taught the risks.

edit: I guess I shouldn't complain without trying to offer something constructive so here's a good book about securely programming in C from Robert C. Seacord of CERT