Is DEP easily evadable?

From: John Richard Moser (nigelenki_at_comcast.net)
Date: 01/12/05

  • Next message: Kelly Martin: "SF new column announcement: A New Tool In The Spam War"
    Date: Wed, 12 Jan 2005 15:30:24 -0500
    To: security-basics@securityfocus.com
    
    

    I'm no security expert, so bear with me here; I just kind of tripped
    over something interesting that I'd like to ask about.

    I was blogging about DEP based on MS' technical documentation and came
    up with a quick and dirty way to use a buffer overflow (we'll assume no
    stackguarding, or that you found a way around it i.e. using a format
    string bug) to kick DEP out of the way. This is pretty much based on
    the PaX documentation and justification for mprotect() restrictions.

    In a normal shellcode attack, you have a simple process involving:
    - Overwrite the return address
    - Spew in some executable code
    - Let RET take PC to that code and hand you control of the program

    With executable protections preventing the stack from being executable,
    such as with DEP, a different process (hopefully) occurs:
    - Overwrite the return address
    - Spew in some executable code
    - Segmentation fault (memory not executable)
    - Program exits, attack fails

    I looked at the fact that Virtual*() functions (similar to mprotect() on
    POSIX systems) can be used to make any area of memory executable. So,
    here's my way:
    - Overwrite the return address
    - Overwrite the stack frame pointer
    - Spew in a stack frame with a return pointer to the code you injected
    - Spew in some executable code
    - Return to a Virtual*() function (don't know nor care which, I'm not
    doing the attack)
    - Mark the code you injected executable
    - Let RET take PC to the code you injected. You win.

    Without mprotect() restrictions OR ASLR, this should be trivial to do,
    right?

    I can't comment on SafeSEH, although I don't see screwing with exception
    handlers as being more interesting to a cracker than injecting your own
    code.

    -- 
    All content of all messages exchanged herein are left in the
    Public Domain, unless otherwise explicitly stated.
    

  • Next message: Kelly Martin: "SF new column announcement: A New Tool In The Spam War"