In EMET's user interface, it is possible to set the SEHOP policy to either "Application Opt Out" or "Application Opt In."(Vista may have had different settings.)

What is the specific difference between these SEHOP settings for Windows 7, and what is the relationship with EMET's SEHOP mitigation?

I have found these sources, Windows ISV Software Security Defenses and Preventing SEH Exploits, to be helpful, they explain the difference between the compiled SEH protection provided by SafeSEH, and the dynamic protection provided by (system) SEHOP. That "the best solution is to build your code to use both: SafeSEH will work on versions of Windows prior to Windows Vista SP1, and SEHOP provides a more comprehensive defense on Windows Vista SP1 and later." The MSDN article also eludes to SEHOP policies for earlier versions of Windows: "SEHOP support was extended in Windows 7 and Windows Server 2008 R2 by permitting applications to opt-in on a per application basis, as opposed to enabling or disabling SEHOP for the entire system." There is also verbiage to per application SEHOP for Windows 7; see the SRD article and registry entry for the IFEO key: DisableExceptionChainValidation

Also, see this EMET forum post: "Various applications on Windows Vista and above are not compatible with EMETs SEHOP, in this case it is advisable to disable SEHOP from EMET and use the System Mitigations SEHOP. Configure the system mitigation SEHOP to Applications Opt-Out"

All of this leads me to think that setting EMET's SEHOP to Opt In, applies SEHOP if the key is set for the app. And if set to Opt Out, then SEHOP is ignored (You have globally disabled system SEHOP.)

If we choose, then EMET's SEHOP mitigation can be used.

Last, reading these forums there is no tool to identify whether a variant of SEHOP is enforced (unlike DEP and ASLR :(

Since I cannot embed links:

• http://msdn.microsoft.com/en-us/library/bb430720.aspx
• http://blogs.technet.com/b/srd/archive/2009/02/02/preventing-the-exploitation-of-seh-overwrites-with-sehop.aspx
• http://blogs.technet.com/b/srd/archive/2009/11/20/sehop-per-process-opt-in-support-in-windows-7.aspx?Redirected=true
• http://social.technet.microsoft.com/Forums/en-US/emet/thread/1617b165-b4ae-4a57-aeb7-e9f3ef78665f

Hi canaryNumber5,

Thank you for including the very useful links to information on SEHOP in one easy to use place. I have found those links to be very useful resources in the past.

The system-wide SEHOP setting applies SEHOP to every running process but not to every DLL loaded within those processes. EMETs SEHOP (i.e. per process SEHOP) applies SEHOP to each DLL loaded within a process. A process can have both system wide and EMETs SEHOP enabled.

In relation to EMETs SEHOP, this can be applied to any process whether or not it supports SEHOP (regardless of any SEHOP settings within the Windows Registry). The Windows Registry settings is used to disable system wide SEHOP for a specific application that does not support it. EMETs SEHOP can still be applied to that application.

Application Opt In means that the application sets a value in the Windows Registry to notify Windows that it is compatible with system wide SEHOP and thus such protection is then enabled. The name of the value to be placed in the Windows Registry is mentioned in the following EMET Support thread:

http://social.technet.microsoft.com/Forums/en-US/emet/thread/d4ece86a-b398-4f0c-9ad8-b4d92cb8383e/#d4ece86a-b398-4f0c-9ad8-b4d92cb8383e

Application Opt Out means that all processes will have system wide SEHOP applied unless they specify using the Windows Registry that they are not compatible with system wide SEHOP.

You are correct, there are no tools that can be used to verify if EMETs SEHOP is being applied to a process.

Please note, the above information is my understanding of how system wide and per process SEHOP operate/function. If there are any errors in my understanding/explanation, please feel free to correct me. I have developed this understanding from using EMET since December 2010.

There is further related information to EMETs SEHOP in the following threads:

http://social.technet.microsoft.com/Forums/en-US/emet/thread/d6a8a945-ea55-4970-8b83-f31f4225085b

http://social.technet.microsoft.com/Forums/en-US/emet/thread/d64fb832-8bd3-44a7-a583-b37c264ad9fc

I hope the above information is of assistance to you. If you have any other questions, please let us know. Thank you.

Please note: I am a volunteer contributor on this forum.

----------------------------------

If you wish to embed/place links in a forum post, your forum account must first be verified.

Please post a reply in the following thread below, this thread is used to speed up the verification process and has already resolved the issue (of not being able to post images or links) for others who posted in that thread. Please note that unfortunately the verification process can take several days to more than a week:

Verify Your Account

http://social.msdn.microsoft.com/Forums/en-US/reportabug/thread/812eb24a-ecbd-46e8-936b-8ae40da72ec3

JanesC_836, Thank you. I agree with your assertions.

I ran a simple test: Set EMET's system wide SEHOP setting, and examined the system's DisableExceptionChainValidation registry key (see KB956607). The changes in EMET are reflected in the registry key:

*(Note, there's a second key to set, and this key controls the per application setting to "opt in" or "opt out" an application from system SEHOP protection. See the SRD article "SEHOP per-process opt-in support in Windows 7")

The insight is spot on.

The system setting for SEHOP and the per application setting are independent of EMET's SEHOP mitigation (the check mark), and the SafeSEH compiler flag.

As I review the Net for discussions on EMET, there is a variety of commentary on what's the right setting for EMET. Given the compatibility issues with (system) SEHOP (with video drivers and other applications [my research/opinion]), no wonder the IT professional selects OptIn (SEHOP disabled), and the security profession picks OptOut (enabled).

Consider this post:

• http://social.technet.microsoft.com/Forums/en-US/emet/thread/d4ece86a-b398-4f0c-9ad8-b4d92cb8383e/#d4ece86a-b398-4f0c-9ad8-b4d92cb8383e

I now understand why that post encountered issues with the combinations of system wide SEHOP settings and EMET SEHOP mitigations; they are all (subtly) different.

The system-wide SEHOP setting applies SEHOP to every running process but not to every DLL loaded within those processes. EMETs SEHOP (i.e. per process SEHOP) applies SEHOP to each DLL loaded within a process. A process can have both system wide and EMETs SEHOP enabled.

Yeah, this is confusing stuff! But that part doesn't sound right -- is there such a thing as per-process SEHOP and per-DLL SEHOP...? I thought it would only apply to processes as a whole, or not.

Anyway, it seems like on Vista SP1+, EMET could/should simply set the DisableExceptionChainValidation value for the program (of course, doesn't work with EMET's wildcards...) if EMET's SEHOP isn't as compatible. But I don't really expect that to happen. :-)

JamesC_86

I agree with what you wrote. Thank you so much for your insight.

I conducted a simple test and can confirm that EMET's SEHOP system-wide policy setting reflects the value of the (kernel) registry key, DisableExceptionChainValidation (see KB956607):

• EMET setting, registry key, Insight by JamesC-86
• Application Opt In, 1 (disabled), "Application Opt In means that the application sets a value in the Windows Registry* to notify Windows that it is compatible with system wide SEHOP and thus such protection is then enabled."
• Application Opt Out, 0 (enabled), "Application Opt Out means that all processes will have system wide SEHOP applied unless they specify using the Windows Registry* that they are not compatible with system wide SEHOP."

*See "SEHOP per-process opt-in support in Windows 7" at:

• http://blogs.technet.com/b/srd/archive/2009/11/20/sehop-per-process-opt-in-support-in-windows-7.aspx

This link shows how to set another registry key, that enables or disables on SEHOP for an application.

I cannot address whether "system SEHOP applies to every process but not to every loaded DLL." OR  "EMET's SEHOP mitigation applies to each loaded DLL." As per comments here, There's no tool or way for me to affirm this. :(

Now consider the combinations of SEHOP protections at:

• http://social.technet.microsoft.com/Forums/en-US/emet/thread/d4ece86a-b398-4f0c-9ad8-b4d92cb8383e/#d4ece86a-b398-4f0c-9ad8-b4d92cb8383e

One of the 4 scenarios crashed their application:

    3. If I set system-wide SEHOP to Opt In and check the SEHOP box for the Chrome process, LastPass crashes.

Well, This thread clarifies that system SEHOP and EMET's SEHOP are different and Opt In turned SEHOP off so EMET's SEHOP mitigation was responsible for crashing the app. (Maybe;)

This thread is important because there are a few posts on the Net stating what the correct system-wide settings are for EMET. Well, it really depends: The IT professional will prefer OptIn (offers the greatest stability since SEHOP is disabled.) The security professional will prefer OptOut (offers the greatest security.) I am simply looking for the explanation of SEHOP so these decisions can be made.

Last, this post may be duplicated. I included an HTML table, hit "submit, and got a warning that my post was subject to review. Not sure when this review will complete. So forgive any duplicate.

Yeah, this is confusing stuff! But that part doesn't sound right -- is there such a thing as per-process SEHOP and per-DLL SEHOP...? I thought it would only apply to processes as a whole, or not.

Hi DR_LaRRY_PEpPeR,

Thats true. What I mean by per process SEHOP is that if you dont have system wide SEHOP enabled and wish to enable it using EMET on a single process, you can.

With regards to per DLL SEHOP, thats a tough one to definitively prove and this is why I wrote the following above:

Please note, the above information is my understanding of how system wide and per process SEHOP operate/function. If there are any errors in my understanding/explanation, please feel free to correct me.

What makes me think that EMET applies SEHOP to a process in this manner (per DLL) is that as mentioned in the following thread where SEHOP was not compatible with Google Chrome:

http://social.technet.microsoft.com/Forums/en-US/emet/thread/d6a8a945-ea55-4970-8b83-f31f4225085b

Yet on my system I have SEHOP enabled for Google Chrome and it works fine. Why else could that be other than my installation of Google Chrome has minimal 3rd party extensions (i.e. DLLs) loaded within it (I only have 1 extension installed and it works fine even with SEHOP enabled).

In addition, my installation of IE 10 has Enhanced Protected Mode and ActiveX filtering enabled. Only a Nvidia driver DLL is loaded by IE and with all EMET mitigations enabled I dont have any issues. Once again I have seen other forum members versions of IE not be compatible with certain EMET mitigations even when they are using the No-Add-ons mode of IE (I presume certain DLLs are still loaded by other installed programs e.g. that Nvidia DLL I mentioned is not loaded due to a browser add-on that I have installed).

Yes, I could be wrong about per DLL SEHOP but this is what the above behavior strongly hints to.

Anyway, it seems like on Vista SP1+, EMET could/should simply set the DisableExceptionChainValidation value for the program (of course, doesn't work with EMET's wildcards...) if EMET's SEHOP isn't as compatible. But I don't really expect that to happen. :-)

True that might be easier for everyone if it did :)

----------------------------------

This thread is important because there are a few posts on the Net stating what the correct system-wide settings are for EMET. Well, it really depends: The IT professional will prefer OptIn (offers the greatest stability since SEHOP is disabled.) The security professional will prefer OptOut (offers the greatest security.) I am simply looking for the explanation of SEHOP so these decisions can be made.

@ canaryNumber5

I received an email with the contents of your new posts (these posts have not appeared in this thread yet):

Microsoft did encourage the use of system wide SEHOP in the following blog post that was previously mentioned but unfortunately it is rarely that simple:

http://blogs.technet.com/b/srd/archive/2009/11/20/sehop-per-process-opt-in-support-in-windows-7.aspx?Redirected=true

I agree with your statement above. Unfortunately only through testing of all your applications can system wide SEHOP Application Opt Out be chosen as the correct setting. It can vary from system to system.

Please note that EMET Notifer/EMET Agent will not be able to assist you in locating incompatibilities with system wide settings (as an aside, EMET Notifer/EMET Agent do not always assist with highlighting incompatibilities with EMET settings either).

I have found that in general system wide SEHOP can be set to Application opt-out and not cause issues. However some of the programs (e.g. older Cyberlink products) I have installed would not begin to install until I had turned off system wide SEHOP. Once the installation was completed, they would work fine with this setting turned on.

@ canaryNumber5:

If you would like any further advice or clarification, please do not hesitate to ask.

I also agree with both you and DR_LaRRY_PEpPeR that these SEHOP settings can be confusing and from experience using SEHOP can be a trial and error process.

Thank you both for your contributions.