locked
DEP broken in EMET 3.5? RRS feed

  • Question

  • I recently discovered that the DEP setting doesn't appear to actually DO anything with EMET 3.5. Anyone else noticed this? EMET 2.1 and 3.0 are fine... I'm using XP.

    The previous versions will set DEP (permanent in Process Explorer) regardless of whether the system is configured for OptIn or OptOut, etc.

    3.5 Tech Preview does nothing, however, and a process' DEP status is determined by the OS setting or the application (calling SetProcessDEPPolicy()).

    There still appears to be references to Get/SetProcessDEPPolicy in the EMET DLL, so not sure what's going on...

    BTW, can anyone confirm that EMET's "DEP" column is supposed to be missing on XP? I swore I saw it back in the summer, but maybe I was only thinking of Windows 7 screenshots! *shrug*


    Friday, March 8, 2013 2:48 PM

All replies

  • Hi DR_LaRRY_PEpPeR,

    Welcome to the EMET Support forum. I can confirm your observations with EMET 3.5 Tech Preview on Windows XP SP3. I have EMET 3.5 Tech Preview enabled for all of the following programs (they do not opt-into DEP by default):

    Notepad++ 6.3

    Ultradefrag 6.0

    YouTubeDownloader 3.9.6

    You might be wondering why I enabled EMET for these applications. Notepad++ can open many types of files. Any application that opens files from elsewhere should use EMET. The YouTubeDownloader connects to the internet and uses the FFMPEG library (older versions of this library have security vulnerabilities). Ultradefrag could be used without EMET but it does not cause any conflict with EMET so I chose to leave EMET enabled.

    As you can see from the screenshot below, Notepad++ shows DEP but not DEP (Permanent) when EMET 3.5 Tech Preview is enabled for it. In addition, DEP was set to system wide Application Opt Out (I had not created exceptions (opt-out) for these applications):

    Direct Link to Image:

    http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/DEPExample2withEMET35TP.jpg

    However when I set DEP to system wide Application Opt In and rebooted. All of the above applications no longer show DEP at all in the Process Explorer DEP column. EMET 3.5 Tech Preview was still enabled for all of these applications:

    Direct Link to Image:

    http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/DEPExample5withEMET35TP.jpg

    From what I can tell DEP, is still being enabled for these applications but EMET 3.5 TP may not be using the OS implementation of DEP hence why it does not show up in Process Explorer. This could be a similar situation for EMETs implementation of ASLR, Process Explorer does not show this type of ASLR.

    I explained this ASLR difference in the following thread:

    http://social.technet.microsoft.com/Forums/en-US/emet/thread/f85f682e-be0d-4989-8d96-7a6fb99a8da2/#85062d24-ea01-411a-8b8e-d24d06ce0e35

    While my explanation in that thread appears to be correct, this is only an educated guess for this issue with DEP and I apologize for making such a guess but let me explain why I am assuming this:

    As you can see from the following screenshots taken using Process Monitor, the registry values for the applications above are queried for their EMET settings and are successfully applied. The only settings that fails is MandatoryASLR. This is expected since Windows XP does not have the ability to use ASLR:

    EMET 3.5 Tech Preview:

    Direct Link to Image:

    http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/DEPExample8withEMET35TP.jpg

    Direct Link to Image:

    http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/DEPExample6withEMET35TP.jpg

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

    EMET 3.0:

    Direct Link to Image:

    http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/DEPExample2withEMET3.jpg

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

    Repeating the above steps but using EMET 3.0 did give the same result that you experienced, namely that Process Explorer now shows DEP(Permanent):

    Direct Link to Image:

    http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/DEPExamplewithEMET3.jpg

    As shown by the Process Monitor trace above, there does not appear to be any difference between the registry keys that are queried by EMET 3.0.

    You mentioned that the DEP column being unavailable using Process Explorer. I have only seen this happen recently on my Windows Vista 64 bit SP2 PC (it used to work fine but not now). I am not sure what causes this or how to resolve it. Perhaps you could try Process Explorer 15.3 (if you have not already done so)?

    My Windows 7 and Windows 8 PCs also show the DEP column.

    If I were you, I would send a short email to the address mentioned at the end of the following blog post (the line just above the Acknowledgements heading):

    http://blogs.technet.com/b/srd/archive/2012/05/15/introducing-emet-v3.aspx

    Since this email address is not intended for technical support on EMET, simply refer Microsoft to this thread on the EMET forum and ask are they are of this issue?

    I wanted to thank you for noticing this issue and for bringing it to the attention of other EMET users.

    By the way, how did you verify that Get/SetProcessDEPPolicy is present in the EMET shim DLL? Did you use a debugger to match the hexadecimal memory address for this function call to within the allocated memory of the EMET DLL? I did not notice a call to this function in the Process Monitor traces (the screenshots that I have provided only show the relevant sections of the traces but I examined the entire traces thoroughly). 

    You may be interested to know that a new beta of EMET 3.5 should be released this month, it may resolve this issue. Some further details about this beta are mentioned in the following thread:

    http://social.technet.microsoft.com/Forums/en/emet/thread/cae1b571-52f2-4df6-8aa2-5ffe3f635c4b

    If anyone else has any further suggestions or input, please feel free to share it in this thread.

    If I can be of any further assistance, please let me know.

    Thank you.

    • Edited by JamesC_836 Sunday, March 10, 2013 3:59 PM Added web link and minor edits
    Friday, March 8, 2013 5:21 PM
  • Hi DR_LaRRY_PEpPeR,

    Welcome to the EMET Support forum.

    Thanks! And yeah, I'd seen your thread/posts about the next EMET version. The links were helpful, and I'm awaiting a new release. :-)

    I just happened to come across this DEP issue while checking stuff after creating a simple DLL to enabled Permanent DEP for ALL processes (via AppInit_DLLs). Its purpose is because I wanted to have the equivalent of AlwaysOn DEP, but with OptOut and exceptions (explicit and implicit by Windows with some packed EXE loaders, et al.) So the DLL checks GetProcessDEPPolicy before calling Set. :^) I just want to rewrite in assembly quick since I think it's fairly simple (but enough for me!) and to learn more before releasing it and some other stuff I want to make (mostly security related, including SRP functionality from XP I hope to restore for Win 7 :-| ). So, this EMET bug doesn't really affect me, since everything has had DEP enabled anyway on my systems, but it would be nice for EMET to do its DEP-thing and make it Permanent for sure on higher-risk, protected programs!

    I also got the recent idea to create an up-to-date, open source EMET GUI/interface/notifier for systems that may not have/want .NET Framework (XP) and with maybe a few improvements. (See NEMET thread here.)

    From what I can tell DEP, is still being enabled for these applications but EMET 3.5 TP may not be using the OS implementation of DEP hence why it does not show up in Process Explorer. This could be a similar situation for EMETs implementation of ASLR, Process Explorer does not show this type of ASLR.

    I explained this ASLR difference in the following thread:

    http://social.technet.microsoft.com/Forums/en-US/emet/thread/f85f682e-be0d-4989-8d96-7a6fb99a8da2/#85062d24-ea01-411a-8b8e-d24d06ce0e35

    While my explanation in that thread appears to be correct, this is only an educated guess for this issue with DEP and I apologize for making such a guess but let me explain why I am assuming this:

    As you can see from the following screenshots taken using Process Monitor, the registry values for the applications above are queried for their EMET settings and are successfully applied. The only settings that fails is MandatoryASLR. This is expected since Windows XP does not have the ability to use ASLR:

    Sorry, "not using the OS implementation of DEP?" :-) Anyway, the registry reading stuff really has nothing to do with what's implemented. e.g. Put a MandatoryASLR value and it will obviously "succeed" in finding the value, but that doesn't change or mean anything. And, I think each mitigation has a "default" value, so if you would delete one of the other values, it would "fail," yet still have a setting applied (everything but ROP stuff is enabled maybe? I just deleted HeapSpray and SEHOP, but they're still enabled).

    And check this: MandatoryASLR IS "enabled" on XP (because enabled is default): see EMET_Settings env var...

    So DEP is definitely broken (also verified on 64-bit 7, for 32-bit processes of course). Luckily this one is easy to verify. Hopefully other mitigations are actually working, other than just EMET_Settings saying so! :-O

    You mentioned that the DEP column being unavailable using Process Explorer. I have only seen this happen recently on my Windows Vista 64 bit SP2 PC (it used to work fine but not now). I am not sure what causes this or how to resolve it. Perhaps you could try Process Explorer 15.3 (if you have not already done so)?

    My Windows 7 and Windows 8 PCs also show the DEP column.

    Not Process Explorer, but the EMET GUI that's missing the DEP column on XP. I guess that's how it's supposed to be... Since GetProcessDEPPolicy doesn't work on other processes in XP. I noticed NEMET shows DEP status (or attempts to, "?" for some processes). Maybe it's reading some chunk from each process... I don't know that much about that (I guess Process Explorer gets it by using a driver or such). I tried using NtQueryInformationProcess before and couldn't get anything. :-/

    If I were you, I would send a short email to the address mentioned at the end of the following blog post (the line just above the Acknowledgements heading):

    http://blogs.technet.com/b/srd/archive/2012/05/15/introducing-emet-v3.aspx

    Since this email address is not intended for technical support on EMET, simply refer Microsoft to this thread on the EMET forum and ask are they are of this issue?

    I wanted to thank you for noticing this issue and for bringing it to the attention of other EMET users.

    I was going to do that first, but figured it might be better here, hehe. I will do so soon I guess, finally.

    By the way, how did you verify that Get/SetProcessDEPPolicy is present in the EMET shim DLL? Did you use a debugger to match the hexadecimal memory address for this function call to within the allocated memory of the EMET DLL? I did not notice a call to this function in the Process Monitor traces (the screenshots that I have provided only show the relevant sections of the traces but I examined the entire traces thoroughly).

    I just saw the Strings in the DLL (in Process Explorer, etc.). :-D

    I didn't think that Process Monitor was an API monitor, is it? I thought it was (and looks like) a combination of the old FileMon and RegMon, but I still haven't checked it out!

    After your post, I did some quick checks with API Monitor (rohitab.com's) and WinAPIOverride and couldn't see any calls either with EMET 3.0 or my "Permanent DEP" DLL, which seems to be loaded later than AppCompat/EMET. I think the API monitors hook too late after the calls have already happened. If I knew what I was doing a bit more, maybe that could be changed.


    Tuesday, March 19, 2013 10:30 AM
  • Hi DR_LaRRY_PEpPeR,

    So, this EMET bug doesn't really affect me, since everything has had DEP enabled anyway on my systems, but it would be nice for EMET to do its DEP-thing and make it Permanent for sure on higher-risk, protected programs!

    Agreed.

    Not Process Explorer, but the EMET GUI that's missing the DEP column on XP. I guess that's how it's supposed to be... Since GetProcessDEPPolicy doesn't work on other processes in XP. I noticed NEMET shows DEP status (or attempts to, "?" for some processes). Maybe it's reading some chunk from each process... I don't know that much about that (I guess Process Explorer gets it by using a driver or such). I tried using NtQueryInformationProcess before and couldn't get anything. :-

    I located a little more information on how EMET sets DEP. In a previous version (v2.0.0.3)(not sure if EMET 3.0 or 3.5 Tech Preview still use this technique). It used the following technique:

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

    With the previous version of EMET the DEP mitigation did not work on Windows Server.

    Does it work now?

    Yes, EMET 2.0.0 can now turn on DEP on Windows Server 2003. With the old version, the DEP policy was ineffective because Windows Server 2003 does not have the SetProcessDepPolicy() API. With the new version of EMET, DEP is enabled though a special process parameter

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

    Extract from the EMET v2.0.0.3 User’s Guide (Page 19): © 2010 Microsoft. All rights reserved.

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

    From what I can tell, I was wrong about EMET using its own implementation of DEP. It seems to use its own method of enabling DEP (as described by Microsoft above) but when it enables DEP, it is actually forcing Windows’ implementation of DEP to be enabled for the process in question.

    I didn't think that Process Monitor was an API monitor, is it? I thought it was (and looks like) a combination of the old FileMon and RegMon, but I still haven't checked it out!

    You are correct, Process Monitor contains the combined features of FileMon and RegMon. I don’t think it is meant to be an API monitor but it does show some of the functions being called by different applications.

    For your reference, more information on using the advanced features of Process Monitor is available in the following video from its co-creator, Mark Russinovich:

    http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/SIA302

    I suggest downloading the WMV file of this video and watching on your PC in fullscreen mode since the browser window can be a little small. The video is large (643 MB) but you can download it late at night and leave your PC turned on so that you don’t have to sit and wait for it to finish downloading.

    As always, if I can be of any further assistance, please let me know.

    Thank you.

    • Edited by JamesC_836 Thursday, March 28, 2013 10:08 AM Minor correction
    Friday, March 22, 2013 5:43 PM
  • Hi DR_LaRRY_PEpPeR,

    This issue appears to be resolved in EMET 4.0 Beta. I tried to reproduce this issue with the new beta using the same steps as I described above in my first post and DEP is enabled for any process protected by EMET even when system wide DEP is set to Application Opt In. The DEP setting in the Control Panel agrees with EMET's system wide DEP status (shown below):

    Direct Links to Images:

    http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/WinXP_SP3_EMET_4_Beta_SystemSettings.jpg

    http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/WinXP_SP3_With_DEP_EMET_4_Beta.jpg

    In the above screenshot, the same 3rd party programs are now protected by DEP. EMET_GUI.exe is not protected by EMET and so does not have DEP enabled (which is correct behavior).

    I hope this helps. Thank you.

    Friday, April 19, 2013 2:24 PM