stack overflow

[zwA4jE8b]

I will be learning about stacks next week in school but am wondering if anyone can give a generalized answer to this.

How can a stack overflow be used to gain access to a system?

I'm sure after much reading and practice I will figure it out but would like to have an understanding of the general concept.

Thanks
-Mike-

p.s. if you are just going to tell me to shut up and go read a book or something like that, please do not bother responding.

[jsmith]

Well, it's really rather complicated.

Actually, more like a stack overrun, not a stack overflow, can be used to gain access to a system.

The general idea is this.

Suppose someone writes a function that reads input from the keyboard or network or something into a fixed-length
array on the stack. Suppose further that the function is not coded to prevent overrun. The input will now fill
the entire fixed-length array on the stack, then start overwriting data that is already on the stack at a higher
memory address. On Intel based systems, stacks grow downward in memory -- from higher memory addresses to
lower. Furthermore, on Intel, the return address from a function is stored on the stack. The idea is that the data
you enter overruns the array and overwrites the return address of the function with a different address -- one
that is directly within the data you entered. Now if the data you entered is valid instructions, you could make
the program do anything you want, essentially. For example, the instructions could be to launch /bin/bash.
The program that was executing is now running /bin/bash instead, using the credentials of the original program.
So if the original program was running with superuser privileges, /bin/bash is now running with superuser
privileges, and now you have full access to anything and everything.

[ultifinitus]

Well done! I second the "simple" explination.

p.s. if you are just going to tell me to shut up and go read a book or something like that, please do not bother responding.

Hey now, I wouldn't see any reason to say that! It's a good question!

[acorn]

that was an awesome answer and makes sense.

[simeonz]

I apologize, but I will hijack the thread with a couple of questions:

1. Do you need exploit for specific build of the specific program (specific executable image) for this to work? Can you do black-box attack on some supposedly unsecured software?

2. Assuming that the OS loader does not relocate the stack's base address, does the hacker try to find a function whose stack frame remains at stationary position or s/he only needs information for the offsets?

(I am looking now at http://en.wikipedia.org/wiki/Address_space_layout_randomization for some related stuff and wondering - who decides that the stack data of C/C++ applications is executable to begin with?)

Regards

[jsmith]

1. In order to execute such an attack, the attacker has to custom build the attack for the exact version of the program
being hijacked.

2. The hacker does not necessarily need to find a function whose stack frame is stationary; however, if the address is not known, it requires the hacker to create executable code that is position independent (not hard, given gcc's -fPIC option).

3. The OS decides whether or not the stack is executable. In order for the hacker to be successful, ie, launch /bin/bash, at a minimum he needs to be able to call either C-library functions such as "system" or use the system call interface directly. To use the C library functions, the hacker must know the address of the system function so he can generate code to call it. In order to know that, he has to know where the loader places libc in the virtual address space of the process, the exact version of libc being used, and the offset of the system function within libc's code segment. The point of address space randomization is that it keeps the hacker from knowing one of the critical pieces of information needed to execute the attack. Another way to defeat the hacker is to make the stack read-write, but not executable.

[simeonz]

jsmith, thanks a bunch. That cleared my misconceptions.

I misunderstood. I thought that the machine code is directly injected onto the stack and the attacker calls it by rewriting the function's return address. Now I see that it would be much easier to redirect the function's return address to the entry point of some library or system routine and overwrite the following bytes with the desired arguments for the call. You don't need permissions, because the program itself pulls the trigger.

Thanks again.

[Duthomhas]

These things are typically easier to do than you would think, as the loader will regularly put things in the same place.

So, for example, if you want to inject code into another process, you can safely assume that KERNEL32.DLL is loaded in the same address space as in your process, and calculate the addresses of kernel functions in the foreign process relative to your process's kernel function's addresses.

Likewise, for libc, et cetera. [edit] Though, admittedly, things other than kernel32 are not as safe a bet...

[zwA4jE8b]

Thank you jsmith. That was an awesome answer!

[zwA4jE8b]

this conversation has given me a lot to work with.

what is a function return address?

so duoas, are you saying that if i write a program that calls kernell32.dll, (for example sake) my programs base address is 1000 and kernell32 is loaded in at 1100. I can assume that another program or process that calls kernel32 also offsets its adress by 100.

sorry if I am confused about the concept. I have been programming for only 3 months now and have been working with pointers, addresses, and arrays. So I find this topic very fascinating.

[zwA4jE8b]

so jsmith, one would basically want to make another process (that has higher privileges) call a function that is in my program to execute code that my program does not have the privilege to run?