From: Omar Herrera (oherreraprodigy.net.mx)
Date: Wed Jun 15 2005 - 19:41:54 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

> -----Original Message-----
> From: Jonas Yorg [mailto:jonasyorggmail.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

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]