I have a question about SEH Overwrite

Question

I am trying SEH Overwrite for vulnerable test programs.

However, overwriting the RET and SEH chains through 41414141 (input value) does not cause the EIP to run as 41414141.

The picture is that the security cookie function is normally executed even though I overwrote the SEH Chain with 41414141.

Could you advise me on this?

I have attached the assembly code here.

link : https://pastebin.com/ic9bzw20

The picture overrides the SEH Chain with 41414141, but is where the Security cookie function is executed.

Thanks.

Answer 1

The SEH overwrite attack requires that the function has registered an SEH handler. The SEH handler address exists below the stack cookie and return address. If you've overwritten the return address then you've written too many data.

The chain's integrity will be checked, and there must be executable memory at the handler address (i.e. 0x41414141) for the handler to execute. In modern Windows, the address is checked before the transfer will occur, so you won't see any exception at that address if it's not valid. It just won't be reached.

Answer 2

There are two things you must check:

1. You overwritten exception handler but, is there any exception occurs?
2. Are there any protection mechanism active for exception handlers?

For first one, most easy exception which you can trigger and not caught until your handler is obviously access violation. You can try to trigger an exception with overwrite a value which referenced before stack cookie checked. Try to overwrite as long as possible for increasing your chance.

There may be another methods like overwriting some variables and structures but not overwriting stack cookie depending your example. Most of the times compiler arranges overflowing buffers close to stack cookie.

For second one, there may be SafeSEH on and off modules loaded in program memory. But, it is not matter for this stage. Despite SafeSEH, SEHOP (Structured Exception Handling Overwrite Protection) may be blocking program to access exception handler. If you done all tests on Windows XP most probably your problem is not SEHOP. I couldn't find proper resources if Microsoft published any update including SEHOP for Windows XP, last time I checked there is no SEHOP support for Windows XP.

SEHOP specifications need two things to be assured according to this article:

• Each SEH structure points to the next structure.
• Last one contains a specific handler pointing to ntdll!_except_handler4