The purpose of the SEHOP mitigation is to prevent an attacker from being able to make use of the Structured Exception Handler (SEH) overwrite exploitation technique.

Cited from Microsoft (read the full article using this link):

The mitigation technique: SEHOP

There are two general approaches that can be considered when attempting to mitigate the SEH overwrite exploitation technique. The first approach involves making changes to the compiled versions of code such that executable files are made to contain metadata that the platform would need to properly mitigate this technique. Microsoft pursued this approach and released a functional mitigation with Visual Studio 2003. This mitigation took the form of a new linker flag known as /SAFESEH. Unfortunately, the need to rebuild executables in combination with the inability to completely handle cases where an exception handler is pointed outside of an image file make the SafeSEH approach less attractive. The details relating to how SafeSEH works are beyond the scope of this article, but more information can be found on MSDN[2].

The second approach involves adding dynamic checks to the exception dispatcher that do not rely on having metadata derived from a binary. This is the approach taken by SEHOP. At a high-level, SEHOP prevents attackers from being able to use the SEH overwrite technique by verifying that a thread’s exception handler list is intact before allowing any of the registered exception handlers to be called. This mitigation technique is made possible because of an implicit side effect of an SEH overwrite. When the majority of stack-based buffer overflows occur, an attacker will implicitly overwrite the next pointer of an exception registration record prior to overwriting the record’s exception handler function pointer. Since the next pointer is corrupted, the integrity of the exception handler chain is broken. This insight, in combination with ASLR, is what allows SEHOP to effectively mitigate SEH overwrites.

From an implementation perspective, SEHOP achieves this functionality in two distinct steps. The first step involves the insertion of a symbolic exception registration record as the tail record in a thread’s exception handler list. This step occurs when a thread first begins executing in user mode. Since exception registration records are always inserted at the head of the exception handler list, the symbolic record is guaranteed to be the final exception registration record.

The second step consists of walking the exception handler list at the time that an exception is being dispatched to ensure that the symbolic record can be reached and that it is valid. This step happens when the exception dispatcher is notified that an exception has occurred in user mode. If the symbolic record cannot be reached, the exception dispatcher can assume that the exception handler list is corrupt and that an SEH overwrite may have occurred. The exception dispatcher is then able to safely terminate the process. If the symbolic record is found, the exception dispatcher is able to proceed as it normally would and call each of the registered exception handlers.