Function is an Exception Handler

The introduction of SafeSEH as a modern compile-time mitigation has caused the particulars of how exception handlers are implemented to become more interesting. This has to do with the fact that SafeSEH restricts the set of exception handlers that may be called by the exception dispatcher to those that are specified as being valid within the scope of a given binary. As discussed previously in this paper, SafeSEH prevents traditional SEH overwrites from being able to use any address as the overwritten exception handler. While this is effective in its primary intent, there is still the possibility that a valid exception handler can be abused to make exploitation more feasible[1]. This scenario is restricted to EH3 and prior exception handlers as EH4 includes a check of a cookie before dispatching exceptions. As such, it may be useful to flag the regions of code that are associated with EH3 and prior exception handlers, including language-specific exception handlers, as being potentially interesting from an exploitation perspective.

Unfortunately, as with ASLR, the benefits offered by SafeSEH are not complete unless every binary that is loaded into a process address space has been compiled to make use of SafeSEH. If a binary has not been compiled to make use of SafeSEH, an attacker may be able to use any address found within the binary's memory mapping as an exception handler in the context of an SEH overwrite. This may make exploitation more feasible.