overwriting SEH and debugging

View: New views
4 Messages — Rating Filter:   Alert me  

overwriting SEH and debugging

by opexoc :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello,

I am in situation that I have successfully overwrite SEH in some app. I know that because when I am debugging this app I get exception ( access violation ) and then I can thanks to go to fs:[0] find out what is in first SEH structure.

I have overwritten this SEH by ordinary \xeb\x30\x90\x90 and address of POP edi/POP esi/RET 8 instruction in shell32 module. I am wondering why when I press SHIFT+F9 in ollydbg I get "Debugged program was unable to process exception". But when I overwrite address of handler in SEH by for example: \x41\x42\x43\x44 then when I press SHIFT+F9 I get that 0x44434241 cannot be accessed - so next exception - as it should be. Where is a problem?

opexoc

Re: overwriting SEH and debugging

by H D Moore :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

This occurs because of a feature known as "SafeSEH". This is a new
compiler flag that creates a list of registered SEH handlers within each
executable and DLL. If your target executable was compiled with /SafeSEH
and you try to return into a module that has been also been compiled with
this feature, but the address you chose is not in the list of registered
handlers, then the exception handling code will not transfer execution.

There are a few options to work around this:

1. On Windows 2003, prior to SP1, SafeSEH was essentially broken and you
can return to DLLs such as "ATL.dll" and a few others without the
registered list being checked.

2. Find a module loaded into memory that was not compiled with this flag.
In the case of non-Microsoft applications, use a return address in a DLL
shipped with the product. There is an OllyDbg plugin that lets you check
all loaded modules for a registered SEH list. I am a lazy bastard and
just use msfpescan:

# Windows XP SP0
$ msfpescan -i ws2help.dll | grep SEHandler
<no results>

# Windows XP SP2
$ msfpescan -i ws2_32.dll | grep SEHandler
SEHandlerTable                 0x71abbcc0
SEHandlerCount                 0x00000001

3. Find another opcode, in-memory, that is not part of a module, but is
still marked executable. A known location on the heap or a loaded
codepage might do the trick. Using a debugger, or tools like memdump.exe
+ msfpescan can simplify this.

More information:

http://www.openrce.org/downloads/details/244/OllySSEH
http://www.immunitysec.com/products-immdbg.shtml
http://msdn2.microsoft.com/en-us/library/9a89h429(VS.80).aspx
http://sf-freedom.blogspot.com/
http://www.milw0rm.com/exploits/4651

-HD

On Thursday 20 December 2007, opexoc@... wrote:

> I am in situation that I have successfully overwrite SEH in some app. I
> know that because when I am debugging this app I get exception ( access
> violation ) and then I can thanks to go to fs:[0] find out what is in
> first SEH structure.
>
> I have overwritten this SEH by ordinary \xeb\x30\x90\x90 and address of
> POP edi/POP esi/RET 8 instruction in shell32 module. I am wondering why
> when I press SHIFT+F9 in ollydbg I get "Debugged program was unable to
> process exception". But when I overwrite address of handler in SEH by
> for example: \x41\x42\x43\x44 then when I press SHIFT+F9 I get that
> 0x44434241 cannot be accessed - so next exception - as it should be.
> Where is a problem?



Re: overwriting SEH and debugging

by Dude VanWinkle :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Dec 20, 2007 12:36 PM, H D Moore <sflist@...> wrote:

> This occurs because of a feature known as "SafeSEH". This is a new
> compiler flag that creates a list of registered SEH handlers within each
> executable and DLL. If your target executable was compiled with /SafeSEH
> and you try to return into a module that has been also been compiled with
> this feature, but the address you chose is not in the list of registered
> handlers, then the exception handling code will not transfer execution.
>
> There are a few options to work around this:
>
> 1. On Windows 2003, prior to SP1, SafeSEH was essentially broken and you
> can return to DLLs such as "ATL.dll" and a few others without the
> registered list being checked.

Does ATL.dll and friends equate to the SEH version of XPSP2's
starforce.dll (where you can turn off DEP by invoking it), meaning
does calling them cancel out all SafeSEH security, or are they just
free from the SafeSEH restrictions by themselves?

I assume its the latter, but just thought I would ask...

-JP<who hopes DRM software needs the same coddling as video games>

Re: overwriting SEH and debugging

by H D Moore :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Just free of SafeSEH restrictions themselves (the flags are slightly
different too).

-HD

On Saturday 22 December 2007, Dude VanWinkle wrote:
> Does ATL.dll and friends equate to the SEH version of XPSP2's
> starforce.dll (where you can turn off DEP by invoking it), meaning
> does calling them cancel out all SafeSEH security, or are they just
> free from the SafeSEH restrictions by themselves?
>
> I assume its the latter, but just thought I would ask...