Why is Windows XP 64 bit DEP (Data Execution Prevention) not working in this example ? (DEP is ON for all programs) - ASM x86 ASM 370

This is a discussion on Why is Windows XP 64 bit DEP (Data Execution Prevention) not working in this example ? (DEP is ON for all programs) - ASM x86 ASM 370 ; Hello, Isn't windows xp 64 bit supposed to prevent these sort of buffers overruns ? I am not really seeing it. This code executes just fine ? How come ? program Project1; {$APPTYPE CONSOLE} // *** begin of buffer overrun ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 10 of 19

Why is Windows XP 64 bit DEP (Data Execution Prevention) not working in this example ? (DEP is ON for all programs)

  1. Default Why is Windows XP 64 bit DEP (Data Execution Prevention) not working in this example ? (DEP is ON for all programs)

    Hello,

    Isn't windows xp 64 bit supposed to prevent these sort of buffers overruns ?

    I am not really seeing it.

    This code executes just fine ?

    How come ?

    program Project1;

    {$APPTYPE CONSOLE}

    // *** begin of buffer overrun exploit example ***

    procedure CallMe;
    begin
    writeln('called');
    readln;
    end;


    procedure ShowMe;
    begin
    writeln('showme');
    readln;
    end;


    procedure BufferOverrun( ParaBuffer : pointer; ParaSize : integer );
    var
    StackBuffer : packed array[0..999] of byte;
    begin
    // copy parameter buffer over stack buffer without length checking


    // move( source, dest, size );
    move( ParaBuffer^, StackBuffer, ParaSize );
    end;


    type
    TbyteArray = packed array[0..3] of byte;


    var
    Exploit : packed array[0..1999] of byte;
    I : integer;
    begin
    // fill exploit with FF
    for i:=0 to 1999 do
    begin
    Exploit[i] := $FF;
    end;


    // location of instruction pointer at offset 1000:


    // offset 1000 location of return address
    // this will get copied into the instruction pointer
    // this code will make the instruction pointer call the procedure CallMe
    // and then return to get the next instruction
    Exploit[1000] := TbyteArray(@CallMe)[0];
    Exploit[1001] := TbyteArray(@CallMe)[1];
    Exploit[1002] := TbyteArray(@CallMe)[2];
    Exploit[1003] := TbyteArray(@CallMe)[3];


    // place your next instruction here
    // this will call show me
    Exploit[1004] := TbyteArray(@ShowMe)[0];
    Exploit[1005] := TbyteArray(@ShowMe)[1];
    Exploit[1006] := TbyteArray(@ShowMe)[2];
    Exploit[1007] := TbyteArray(@ShowMe)[3];

    BufferOverrun( @Exploit, 1999 );

    readln;
    end.

    Bye,
    Skybuck.


  2. Default Re: Why is Windows XP 64 bit DEP (Data Execution Prevention) not working in this example ? (DEP is ON for all programs)


    "Skybuck Flying" <spamtrap@crayne.org> wrote in message
    news:447424cb$0$710$5fc3050@dreader2.news.tiscali.nl...
    > Hello,
    >
    > Isn't windows xp 64 bit supposed to prevent these sort of buffers overruns
    > ?


    No, DEP doesn't stop you from overwriting the stack, it stops you from
    executing *code* on the stack. So it doesn't detect all viruses.

    Wilco


  3. Default Re: Why is Windows XP 64 bit DEP (Data Execution Prevention) not working in this example ? (DEP is ON for all programs)


    "Wilco Dijkstra" <spamtrap@crayne.org> wrote in message
    news:2f2dg.4341$XR6.3058@newsfe2-gui.ntli.net...
    >
    > "Skybuck Flying" <spamtrap@crayne.org> wrote in message
    > news:447424cb$0$710$5fc3050@dreader2.news.tiscali.nl...
    >> Hello,
    >>
    >> Isn't windows xp 64 bit supposed to prevent these sort of buffers
    >> overruns ?

    >
    > No, DEP doesn't stop you from overwriting the stack, it stops you from
    > executing *code* on the stack. So it doesn't detect all viruses.


    Why is ShowMe executed ?

    It's just an address on the stack.

    The instruction pointer will point to this address and will execute it as if
    it were an instruction if I am not mistaken ?

    Bye,
    Skybuck.


  4. Default Re: Why is Windows XP 64 bit DEP (Data Execution Prevention) notworking in this example ? (DEP is ON for all programs)

    Skybuck Flying schrieb:
    > "Wilco Dijkstra" <spamtrap@crayne.org> wrote in message
    > news:2f2dg.4341$XR6.3058@newsfe2-gui.ntli.net...
    >
    >>"Skybuck Flying" <spamtrap@crayne.org> wrote in message
    >>news:447424cb$0$710$5fc3050@dreader2.news.tiscali.nl...
    >>
    >>>Hello,
    >>>
    >>>Isn't windows xp 64 bit supposed to prevent these sort of buffers
    >>>overruns ?

    >>
    >>No, DEP doesn't stop you from overwriting the stack, it stops you from
    >>executing *code* on the stack. So it doesn't detect all viruses.

    >
    >
    > Why is ShowMe executed ?
    >
    > It's just an address on the stack.
    >
    > The instruction pointer will point to this address and will execute it as if
    > it were an instruction if I am not mistaken ?


    You are overwriting the return address on the stack. By returning from
    the function, the CPU jumps to this new address instead of the address
    it should return to before.
    You haven't deployed any _machine code_ on the stack which DEP would
    prevent to execute, you are just manipulating the return addresses.

    Thomas


  5. Default Re: Why is Windows XP 64 bit DEP (Data Execution Prevention) not working in this example ? (DEP is ON for all programs)


    "Skybuck Flying" <spamtrap@crayne.org> wrote in message
    news:4474c064$0$748$5fc3050@dreader2.news.tiscali.nl...
    >
    > "Wilco Dijkstra" <spamtrap@crayne.org> wrote in message
    > news:2f2dg.4341$XR6.3058@newsfe2-gui.ntli.net...
    >>
    >> "Skybuck Flying" <spamtrap@crayne.org> wrote in message
    >> news:447424cb$0$710$5fc3050@dreader2.news.tiscali.nl...
    >>> Hello,
    >>>
    >>> Isn't windows xp 64 bit supposed to prevent these sort of buffers
    >>> overruns ?

    >>
    >> No, DEP doesn't stop you from overwriting the stack, it stops you from
    >> executing *code* on the stack. So it doesn't detect all viruses.

    >
    > Why is ShowMe executed ?


    Because BufferOverrun jumps to CallMe when it returns (as you've
    overwritten its return address). When Callme returns it pops the next
    address from the stack, ShowMe, and so it jumps there.
    If you set Exploit[1008..1011] to another function it will call that too
    etc.

    > It's just an address on the stack.
    >
    > The instruction pointer will point to this address and will execute it as
    > if it were an instruction if I am not mistaken ?


    No. The stack pointer points to the stack, the instruction pointer doesn't.
    On x86 when a function returns it pops the return address from the top of
    the stack, so by overwriting the stack you can call any set of functions.
    All DEP does is prevent you from inserting your own code on the
    stack, something other architectures have supported for decades.

    Wilco


  6. Default Re: Why is Windows XP 64 bit DEP (Data Execution Prevention) not working in this example ? (DEP is ON for all programs)

    Skybuck Flying wrote:
    > "Wilco Dijkstra" <spamtrap@crayne.org> wrote in message
    > news:2f2dg.4341$XR6.3058@newsfe2-gui.ntli.net...
    >>
    >> "Skybuck Flying" <spamtrap@crayne.org> wrote in message
    >> news:447424cb$0$710$5fc3050@dreader2.news.tiscali.nl...
    >>> Hello,
    >>>
    >>> Isn't windows xp 64 bit supposed to prevent these sort of buffers
    >>> overruns ?

    >>
    >> No, DEP doesn't stop you from overwriting the stack, it stops you
    >> from executing *code* on the stack. So it doesn't detect all viruses.

    >
    > Why is ShowMe executed ?
    >
    > It's just an address on the stack.
    >
    > The instruction pointer will point to this address and will execute
    > it as if it were an instruction if I am not mistaken ?


    DEP doesn't stop you from overwriting the return-EIP on the stack - it stops
    you from putting (shell)code on the stack, pointing return-EIP to the stack,
    and thus executing from the stack. You also can't execute directly from
    HeapAlloc()'ed memory, and must now either VirtualProtect() or
    VirtualAlloc() with the right flags.


  7. Default Re: Why is Windows XP 64 bit DEP (Data Execution Prevention) not working in this example ? (DEP is ON for all programs)


    Skybuck Flying wrote:
    > "Wilco Dijkstra" <spamtrap@crayne.org> wrote in message
    > news:2f2dg.4341$XR6.3058@newsfe2-gui.ntli.net...
    > >
    > > "Skybuck Flying" <spamtrap@crayne.org> wrote in message
    > > news:447424cb$0$710$5fc3050@dreader2.news.tiscali.nl...
    > >> Hello,
    > >>
    > >> Isn't windows xp 64 bit supposed to prevent these sort of buffers
    > >> overruns ?

    > >
    > > No, DEP doesn't stop you from overwriting the stack, it stops you from
    > > executing *code* on the stack. So it doesn't detect all viruses.

    >
    > Why is ShowMe executed ?
    >
    > It's just an address on the stack.
    >
    > The instruction pointer will point to this address and will execute it as if
    > it were an instruction if I am not mistaken ?



    No, the return address is just a piece of data on the stack. It's
    loaded into the instruction pointer by the return (ret) instruction at
    the end of the routine. Overwrite the return address and ret will
    wander off to who-knows-where.


  8. Default Re: Why is Windows XP 64 bit DEP (Data Execution Prevention) not working in this example ? (DEP is ON for all programs)

    In comp.lang.asm.x86 robertwessel2@yahoo.com <spamtrap@crayne.org> wrote in part:
    > No, the return address is just a piece of data on the stack.
    > It's loaded into the instruction pointer by the return (ret)
    > instruction at the end of the routine. Overwrite the return
    > address and ret will wander off to who-knows-where.


    Absolutely correct. This is in fact how virii start executing.
    The virus loads by overflowing a gets() buffer with it's own code
    which also replaces the return address with a pointer to itself.

    -- Robert



  9. Default Re: Why is Windows XP 64 bit DEP (Data Execution Prevention) not working in this example ? (DEP is ON for all programs)

    Another item is that the newer Microsoft compilers have code that will
    add a 'barrier' to on stack buffers that if it is altered when the
    code is returning from a function, will trap and not execute the
    return. Some newer versions of this routine uses random values in the
    barrier so that viral code can't just replace the barrier with the
    known values.

    On Wed, 24 May 2006 23:12:39 GMT, Robert Redelmeier
    <redelm@ev1.net.invalid> wrote:

    >In comp.lang.asm.x86 robertwessel2@yahoo.com <spamtrap@crayne.org> wrote in part:
    >> No, the return address is just a piece of data on the stack.
    >> It's loaded into the instruction pointer by the return (ret)
    >> instruction at the end of the routine. Overwrite the return
    >> address and ret will wander off to who-knows-where.

    >
    >Absolutely correct. This is in fact how virii start executing.
    >The virus loads by overflowing a gets() buffer with it's own code
    >which also replaces the return address with a pointer to itself.
    >
    >-- Robert
    >



  10. Default Re: Why is Windows XP 64 bit DEP (Data Execution Prevention) notworking in this example ? (DEP is ON for all programs)

    Robert Redelmeier wrote:
    > In comp.lang.asm.x86 robertwessel2@yahoo.com <spamtrap@crayne.org> wrote in part:
    >> No, the return address is just a piece of data on the stack.
    >> It's loaded into the instruction pointer by the return (ret)
    >> instruction at the end of the routine. Overwrite the return
    >> address and ret will wander off to who-knows-where.

    >
    > Absolutely correct. This is in fact how virii start executing.
    > The virus loads by overflowing a gets() buffer with it's own code
    > which also replaces the return address with a pointer to itself.
    >
    > -- Robert
    >
    >



    Except the virus needs to place its own code on the stack too via the
    overflow of gets. In this case the code is part of the executable text
    already. If we were drawing an ****ogy of this example to a virus I would
    say the file is already infected.

    The NX bit is meant to prevent execution of code on stack pages by marking
    them non executable. It does not prevent corruption of the stack itself
    by buffer overruns. That will most likely cause the program to crash, not
    an infectious payload to be executed.


+ Reply to Thread
Page 1 of 2 1 2 LastLast

Similar Threads

  1. Replies: 9
    Last Post: 11-14-2007, 05:31 PM
  2. Data management... but Execution halts!!! T.T
    By Application Development in forum Idl-pvwave
    Replies: 18
    Last Post: 11-15-2006, 08:53 PM
  3. How to measure execution time of Cg programs
    By Application Development in forum Graphics
    Replies: 5
    Last Post: 07-18-2006, 01:21 PM
  4. data recovery programs
    By Application Development in forum Hardware
    Replies: 3
    Last Post: 11-11-2004, 04:56 PM
  5. Replies: 1
    Last Post: 10-05-2004, 04:12 PM