Vulnerability Development mailing list archives
RE: the possibility of jumping back to code in an exploited program
From: Omar Herrera <oherrera () prodigy net mx>
Date: Wed, 15 Jun 2005 19:41:54 -0500
-----Original Message----- From: Jonas Yorg [mailto:jonasyorg () gmail com] So I heard somewhere once that supposedly a buffer-overflowing program can jump back into the code it's exploiting in order to call some system call (after setting up the appropriate stack/register environment I would suppose). I think that whoever I read heard from was maybe thinking of return to libc type exploits where you jump to some libc wrapper for a system call. Anyway my question is this (for both linux and windows, but mainly linux for now): Is it possible to directly jump back to code in the program you exploited?
Sure it is possible, this is not exactly an overflow but will illustrate the concept, try it out. It should compile and work as expected with most Linux distributions (unless you change some compiler/linker options): --- #include <stdio.h> void function(int a, int b, int c) { char buffer1[4]; char buffer2[4]; unsigned long *ret; ret = (unsigned long) buffer1 + 8; *ret += 7; printf("values of a, b and c: %d %d %d\n",a,b,c); } int main() { int x; x = 0; function(1,2,3); x = 1; printf("Value of x is: %d \n",x); return(0); } --- It is very similar to example3.c from "Smashing the Stack for Fun and Profit" by Aleph One. At function "function", you manipulate (increment) the value of the return address, so that it points to the printf instruction, therefore, the result printed on the screen is "x=0" and not x=1 (you jump over this instruction. Now, in an exploit, if you have the source code you can work it out more or less the same. Instead of trying to fix the return address so that it jumps to your injected shellcode, you could search for the address within the executable program where you want it to jump to. Since x86 processors use Little Endian to store addresses, you don't necessarily need to overwrite the whole EIP on the stack.
I've been running some tests with linux which lead me to believe it's not possible, but I realize that I don't know for sure that it isn't my coding mistake. So here's the setup. I've got a simple program with the standard strcpy type overflow of the stack return address...(well except that I'm using memcpy during development so I don't have to be all clever about restricted characters until I get it working ;) So my vulnerable server has a socket, bind, listen, and accept call in that order before it waits for input (obviously). So I'm going to use bind for this example because I've also been using kdb to see what things look like in the kernel depending on the attack (that's the research :) and bind is less likely to be called by something else while I'm messing around...So if I overflow the buffer with the libc address for bind (as found by "disassemble bind" from in gdb) it jumps there fine and picks up execution. However, if I set the address to the bind call in my main program for some reason it always jumps to 0x3fbf8. I know that this value doesn't mean anything in and of itself but here's what I learned about it...right before the ret instruction after the leave has been executed %ebp is set to 0x3fbf8 and looking at memory I can confirm that it is what is on the stack immediately lower than my ret address... however %esp IS pointing to my desired return address at the time that the ret is executed. So in this case I would have said that maybe the %esp pointer is confuse or something which makes the ret pop the previous value off the stack and jump to it instead of the one that gdb says that %esp is pointing to (or gdb is confused I don't know)
Well, jumping to code inside the program is not exactly the same as jumping to library functions that are called within a program. The address you see in your program most likely is pointing to the .PLT, Procedure linkage table (if I remember correctly how this stuff works). This, in turn, should be a jump instruction, which uses an offset at the .GOT (Global Offset Table) which is dynamically changed at runtime, I think. Perhaps that is what is messing you exploit. This might help clarify things a little bit: http://www.zone-h.org/files/24/elf_runtime_fixup.txt. I'm not sure how you could exploit it actually (calling the library function within the exploited program, directly from the shellcode or on the overflow of EIP). But probably someone else can help us here :-). Kind regards, Omar Herrera
Current thread:
- the possibility of jumping back to code in an exploited program Jonas Yorg (Jun 15)
- RE: the possibility of jumping back to code in an exploited program Omar Herrera (Jun 16)