SEH overwrite attack details

Question

If there are canaries on stack, why does not the exception handler check the integrity of canaries? Why does it continue executing a manipulated exception handler?

Will corrupting a canary trigger an exception? Is this a common way to trigger an exception at SEH overwrite attacks?

Why does the attack have to set the handler address to "pop-pop-ret", then jumping to the destination address, e.g., inserted shell code? I mean, why not set the handler address directly to the destination address?

I understand there are mitigation now against such attacks, I still want to know more details. Thanks.

Ref: https://www.exploit-db.com/docs/17505.pdf

Answer 1

1. The exception handler does not check the integrity of the canaries since the check code is called only when the function terminates. The attacker sould make sure that before the program reaches that code, an exception should be thrown!

2. Without further protections, the program continues to execute a manipulated exception handler because it does not know that it is malformed.

3. Corrupting a canary will not trigger an exception, the program will not know that the canary has changed until the integrity check. Overflowing a buffer, on the other hand, MIGHT trigger an exception (If, for example, the attacker overruns a pointer and points it to an area that is unreadable/unwriteable and then tries to read/write with that pointer).

4. Assuming that the shellcode is on the stack, we do not place the address of the shellcode in the address of the exception handler because Windows has a some basic defence mechanism that prevents exceptions from jumping to addresses on the stack. SEH was abused commonly and repeatedly, and so it was created. Therfore, we use pop, pop, ret because we can easily find this code in the text segment (an area the exception handler CAN jump to).

5. For more details about the mitigation techniques please read about:

   • SafeSEH which defines exact addresses that allow exceptions to jump to them.
   • SEHOP which verifies the integrity of the exception handler list.

I also asked a question on the subject, you might want to take a look at it