Partager via

EMET and DEP

  • Article

 

I’ve seen various questions recently around the use of EMET and DEP for protecting processes.  Prior to launching into this I highly recommend reading Rob Hensing’s old but good articles on this at https://blogs.technet.com/b/srd/archive/2009/06/12/understanding-dep-as-a-mitigation-technology-part-1.aspx and https://blogs.technet.com/b/srd/archive/2009/06/12/understanding-dep-as-a-mitigation-technology-part-2.aspx .

Getting first things out of the way DEP is an OS/System Mitigation.  EMET does not have a mitigation called DEP it merely makes it easier to configure DEP for the OS as a whole as well as the ability to opt-in applications that were not compiled with DEP configured or the ability to opt-out applications if the OS is set to DEP always-on.

This is the issue I’ve typically seen with EMET + DEP + process:

    • System is set to DEP Opt-In (i.e. processes don’t run with DEP enabled unless compiled that way for x86 apps x64 is a different story as they are always DEP)
    • application.exe is either an x86 or x64 application that is compiled as a DEP aware application
    • EMET also is protecting application.exe and has the DEP box checked for application.exe

So demonstrating a lab setup I have three applications shown in the pic below that are exactly what the app names state

  • x64AppCompiledWDEP.exe = x64 application with DEP enabled
  • x86AppCompiledWDEP.exe = x86 application compiled with DEP enabled
  • x86AppCompiledWODEP.exe = x86 application compiled with DEP not enabled or the NXCOMPAT linker option set to NO (see https://msdn.microsoft.com/en-us/library/ms235442.aspx)

image

So at times (I unfortunately can’t repro this in my lab) having this setup for the x86AppCompiledWDEP.exe application will cause application crashes with whatever that application is (have seen it happen to IE and Office applications among others).  The proper way usually to fix this is to ensure that EMET does not try to opt-in this process to DEP as it is already using DEP in most cases.  In you EMET configuration find the application with the issues and uncheck the DEP box.  The big push back I typically get here is that you are turning off mitigations this is not good etc and this is absolutely not the case if this is already a DEP aware application. The next slide shows the same applications with the DEP box unchecked for each of the applications that previously had it checked on a system that has DEP set to OPT-IN.

image

Notice in the Task manager section (btw I right clicked on the columns and added the Data Execution Prevention / DEP column) that DEP is still enable for both the x64 application as well as the x86 application that was compiled as DEP aware.  It is not however enabled any more for the x86 application that was not compiled with DEP which means in the first screenshot that EMET was actually working quite well and opting my non-DEP application into the OS DEP mitigation at process startup.

So the point of this article is basically if you are seeing crashes for an application and it turns out to be because EMET is attempting to opt-in an application to DEP,  unchecking the DEP box for that application may fix the problem. Also if the application is a recent version of IE/Office etc that is already using DEP (use task manager to check on that) you will not be lowering or changing your security posture in any way.

Thanks

Kurt

Comments

  • Anonymous
    January 05, 2016
    Thanks a ton for this post. I've been doing this all wrong and getting crashes as a result (Excel mainly). I'll get to correcting all of this tomorrow when I get in the office. Any authoritative lists of DEP and non-DEP compiled applications?