Buffer overflow exploitation with execve() - Minix

This is a discussion on Buffer overflow exploitation with execve() - Minix ; So I'm currently taking an operating systems course where we are studying the latest Minix3 (really interesting stuff). We wrote a device driver that can simply take a string such as "caps=on" and send the command to the LED driver ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Buffer overflow exploitation with execve()

  1. Buffer overflow exploitation with execve()

    So I'm currently taking an operating systems course where we are
    studying the latest Minix3 (really interesting stuff). We wrote a
    device driver that can simply take a string such as "caps=on" and send
    the command to the LED driver [ echo "caps=on" > /dev/led ] and it
    turns on the keyboard LED. As a side project i've decided to try to
    exploit the buffer that I accept this string into to try to launch a
    shell. Now I've studied Alephs one paper on smashing the stack, but
    have come across some problems trying to apply it to Minix. I believe
    my main obstacle is the fact that instead of simply loading the
    registers and calling the int instruction, I have to compose the
    message (execve()s job), then set the regs like syscal and sendrec do,
    then call the int instruction. This seems to be a little trickier
    because execve also calls sbrk to allocate the new stack frame.

    So i'm thinking, if my led driver already has a system call, it should
    have all the code in there for the syscal/sendrec/sbrk etc, so
    shouldn't I then just be able to setup the message and then call
    syscal? I should be able to still call sbrk from the evil buffer code
    right?

    Is this a bad idea to try to rely on the existing functions? Will this
    work? If not should i be able to just use the code from the relevant
    sections of syscal/sbrk/sendrec?

    Thanks for ANY information, its truly apreciated.


  2. Re: Buffer overflow exploitation with execve()

    All,

    On 5 Mar 2006 05:31:54 -0800, wpspam@gmail.com wrote:
    > So I'm currently taking an operating systems course where we are
    > studying the latest Minix3 (really interesting stuff). We wrote a
    > device driver that can simply take a string such as "caps=on" and send
    > the command to the LED driver [ echo "caps=on" > /dev/led ] and it
    > turns on the keyboard LED. As a side project i've decided to try to
    > exploit the buffer that I accept this string into to try to launch a
    > shell. Now I've studied Alephs one paper on smashing the stack, but
    > have come across some problems trying to apply it to Minix. I believe
    > my main obstacle is the fact that instead of simply loading the
    > registers and calling the int instruction, I have to compose the
    > message (execve()s job), then set the regs like syscal and sendrec do,
    > then call the int instruction. This seems to be a little trickier
    > because execve also calls sbrk to allocate the new stack frame.
    >
    > So i'm thinking, if my led driver already has a system call, it should
    > have all the code in there for the syscal/sendrec/sbrk etc, so
    > shouldn't I then just be able to setup the message and then call
    > syscal? I should be able to still call sbrk from the evil buffer code
    > right?


    If your led driver is linked with the library that contains execve(),
    then you should be able to call that.

    To make classic buffer overflows work, you'll need to compile your
    driver to give it a common I and D segment, which isn't the default -
    otherwise you can't return to the address in the stack as there is a
    separate code segment.

    > Is this a bad idea to try to rely on the existing functions? Will this
    > work? If not should i be able to just use the code from the relevant
    > sections of syscal/sbrk/sendrec?


    Try to get any buffer overflow to work (and execute your own
    code under controlled conditions) before trying to make a system
    call.

    =Ben



+ Reply to Thread