overflowing return address to point to stack - Minix

This is a discussion on overflowing return address to point to stack - Minix ; Hello. I've been experimenting with overflowing a buffer to change the return address. I've had success with say incrementing the return address to skip the next instruction in the funtion to which the return address points to. But when i ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: overflowing return address to point to stack

  1. overflowing return address to point to stack

    Hello. I've been experimenting with overflowing a buffer to change the
    return address. I've had success with say incrementing the return
    address to skip the next instruction in the funtion to which the return
    address points to. But when i change it to point into the stack (where
    i have some code sitting). When i do this it gives me a Memory fault -
    core dumped. Now is this because its trying to load something from the
    stack? Or am i somehow setting the return address wrong (i dont think
    so).

    My suspicion is that you can't return into the stack and this is
    causing the memory fault. Any ideas or how i can debug this further? I
    use MDB to step through it, but when it gets to the ret (where it
    should be loading my modified addr that points into the stack) it won't
    proceed any furthur which makes me think its a problem with not being
    allowed to return into the stack.

    Any help would be GREATLY appreciated, thank you


  2. Re: overflowing return address to point to stack

    In this case your process has a separate text and data segment. The
    processor only allows code from the text segment to be executed and since
    the stack resides in the data segment, it causes a segmentation fault when
    you try to do so. So you can't return to code you've "injected" yourself.

    The story would be different for processes with shared text and data
    segments, in which case the processor cannot distinguish between
    instructions and data. You could play around with that...

    Peter Boonstoppel
    Vrije Universiteit, Amsterdam



+ Reply to Thread