The reason I ask is when I had DEP enabled for all programs without any exceptions through computer properties Yahoo Messenger worked fine. After installing EMET 4.0 and adding Yahoo Messenger to its protected apps it fails to run unless I uncheck DEP.

Windows 7, Service Pack 1, 64-bit.

I wanted to confirm what I said above was true so I uninstalled EMET rebooted then turned on DEP for all programs and services through system properties and Yahoo Messenger does work. I can't figure out what EMET's doing that's not allowing messenger to open. I would have figured that DEP's the same whether through system properties or through EMET but I guess not.

In my experience with DEP realated errors there IS a difference. 

For example, I have an application (MS Money) that will fail when I have the EMET setting of Always On.

In this situation the DEP settings through System Properties are greyed out. Running like this ANY attempt

to execute code from the stack will fail. In fact the MS Money failure is caused by a dll not the MS Money

executable itself.

Now, if I change EMET to say DEP to "Application Opt Out" AND keep the DEP flag checked in EMET, MS Money

will run fine. So it would appear that the dll is not being checked, only the executable.

Furthermore, setting the system properties to DEP for all programs and services allows MS Money to run.

So rather like you, when EMET sets DEP to always on, it's more restrictive than when using the DEP

setting through System Properties, certainly with regard to catching violations from DLL's rather than

executables.

Hi Ashley and thanks for sharing your experience with EMET with me.

I went ahead and reinstalled EMET and under system I set everything to opt-in, but under applications for Yahoo Messenger I unchecked DEP. Would it be safer to have application opt out like you do with DEP check marked next to the app?

I also have one more question. When I installed EMET I let the Installer populate the applications section but a lot of those apps I don't have installed on my system does that matter?

Hi bf-109 and AshleyST,

Thanks for sharing your experiences and knowledge in this thread. The internals of how EMET applies mitigations to our programs is something that I am really interested in.

This weekend I hope to test out Yahoo Messenger on Windows 7 64 bit to try to gather more information about this question.

In previous threads that I have contributed to, we have found that there are differences to how EMET applies SEHOP. EMETs ASLR is well documented as being different too and that has also been explored in previous threads:

Explain: SEHOP System-wide policy setting:

http://social.technet.microsoft.com/Forums/security/en-US/311605cc-04b8-420b-b211-4c4cbdd27133/explain-sehop-systemwide-policy-setting

Difference between OS ASLR and EMET ASLR?

http://social.technet.microsoft.com/Forums/security/en-US/70f0e91a-1b37-400f-826d-97a56d392c15/difference-between-os-aslr-and-emet-aslr

Difference between native system ASLR and EMET imposed system ASLR

http://social.technet.microsoft.com/Forums/security/en-US/c3d19865-f569-4cce-807f-9ff9a8131eea/difference-between-native-system-aslr-and-emet-imposed-system-aslr

Configure Apps: does not take effect

http://social.technet.microsoft.com/Forums/security/en-US/f85f682e-be0d-4989-8d96-7a6fb99a8da2/configure-apps-does-not-take-effect

It will be interesting to find out more about how DEP is applied and I hope that more forum members can also contribute.

I will report back as soon as I can. Thanks again and have a great day.

 Would it be safer to have application opt out like you do with DEP check marked next to the app?

I also have one more question. When I installed EMET I let the Installer populate the applications section but a lot of those apps I don't have installed on my system does that matter?

 Application Opt-Out will obviously catch more programs. With this setting, the only way EMET will not check

the program for violations is if the application EXPLICITLY switches that setting off.

With application opt-in, the application has to request that it be checked, therefore many older programs

that were compiled with out-of-date options will never get looked at.

I wouldn't worry about having entries in the table that are unused, the additional overhead of EMET checking

for an application match will be minimal, especially in relation to all the other code that the system is executing :-)

Thanks Ashley, I did try what you did with Microsoft Money and switch to DEP opt out on system but leave dep checked in apps but Messenger still wouldn't load. Oh well at least I know now which settings works with Yahoo Messenger. I tried searching online to find out if Yahoo Messenger was DEP compatible but I can't find any information at all about that. I wish I could still use Windows Live Messenger instead. 

Thank you also James but you don't have to go through all the trouble of installing something you don't want on your system just to test its dep compatibility for me. Unless its just like a hobby to you and something you enjoy doing.

Thank you both again. :D 

Hi bf-109 and AshleyST,

@bf-109: Its not a problem since I use virtual machines to carry out such testing. My actual PC runs Windows 8 Pro 64 bit but I have several VMs with older versions of Windows for testing purposes. I can revert to an earlier snapshot once I have finished testing Yahoo Messenger, reverting all of the changes it has made.

I setup Yahoo Messenger v11.5.0.228 on Windows 7 Professional 64 bit SP1. I initially had the DEP settings of Windows set to Always on. Yahoo Messenger installed and initially worked correctly. Ymsgr_tray.exe (that runs at Windows start-up is also not compatible with System-wide DEP set to always on). Rebooting after installing Yahoo Messenger with system-wide DEP set to Always On resulted in Yahoo Messenger and Ymsgr_tray.exe not working.

Next, I set DEP to Application Opt In and rebooted (i.e. DEP is off unless the application was compiled using the NXCOMPAT flag of Visual Studio). Both Yahoo Messenger and Ymsgr_tray.exe then worked correctly.

I have previously discussed the default compiler security settings of Visual Studio settings in the following EMET thread (refer to the posts dated: May 12th, 15th 2013):

http://social.technet.microsoft.com/Forums/security/en-US/0b10c1e4-cbdb-4dba-af3a-1fdf3a7a6a98/emetconf-will-not-open-and-emetnotifier-never-notifies

Next I uploaded the DLLs and .EXE files from within the following folders to a tool called SlopFinder available from the following link that analyzes DLLs and EXE files for compatibility with DEP and ASLR. Please find below those results:

http://icebuddha.com/slopfinder.htm

http://0xdabbad00.com/2012/12/05/finding-slop-common-windows-apps-still-without-dep-and-aslr/

The list of DLLs used by Yahoo Messenger upon launch are shown in the following 2 screenshots from Process Explorer:

Direct Links to Images:

http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/YahooMsgDLLs.png

http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/YahooMsgDLLs2_HL.png

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

Part 1 all DLL and EXE files from:

C:\Program Files (x86)\Yahoo!\Messenger

Direct Link to Image:

http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/YahooMsgSecurityResults.png

Next I repeated the above for the following folder:

C:\Program Files (x86)\Yahoo!\Messenger\resources\en-US

Direct Link to Image:

http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/YahooMsgSecurityResults2.png

Finally for the remaining folder:

C:\Program Files (x86)\Yahoo!\Shared

                    

Direct Link to Image:

http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/YahooMsgSecurityResults3.png

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

As you can see, the results make for poor reading. Only 1 DLL, pcre.dll from:

C:\Program Files (x86)\Yahoo!\Messenger

was compiled with DEP and ASLR. I am not sure why this DLL was protected when all others werent. This file appears to check and manipulate strings of text (as expected of instant messaging program), makes uses of the POSIX thread model and uses some rather strange APIs (for an instant messaging program) e.g. TerminateProcess as shown in the screenshot below:

Direct Link to Image:

http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/YahooMsgPCRE_APIs.png

Upon adding YahooMessenger.exe and Ymsgr_tray.exe to the list of EMET protected applications (I had enabled all EMET mitigations including the Deep Hooks mitigation) caused Yahoo Messenger to no longer open (this was the same behavior when System-wide DEP was always on). Given the lack of DEP and ASLR support from all but one of the above DLLs, this is not surprising. Disabling DEP (within EMET) for YahooMessenger.exe resulted in it launching successfully again (System-wide DEP was set to Application Opt-In). The same was necessary for Ymsgr_tray.exe

After enabling EMET for Yahoo Messenger, as shown by the following screenshots that only 2 of the DLLs loaded by it are actually randomly placed (due to EMETs Mandatory ASLR). For these DLLs (shown in pink), we can see that the Base address of the DLL (where the DLL is placed in memory) does not match the actual image base address (its desired or preferred address as specified by the programs developers) and this is a good thing since ASLR has taken affect:

Direct Links to Images:

http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/YahooMsgDLLs3.png

http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/YahooMsgDLLs4.png

Closing and re-opening Yahoo Messenger results in ft60.dll being placed at a different location in memory (i.e. 0x52B0000 instead of 0x4FD000 from the first time I launched Yahoo Messenger).

Differing from the conclusion from the above mentioned ASLR and SEHOP threads, from what I can tell, EMET is applying DEP in the same way as Windows would, supporting AshleySTs observations.

As explained in the following blog post, once DEP is enabled for an .EXE file all DLLs within that .EXE benefit from the protection of DEP:

http://0xdabbad00.com/2012/12/07/dep-data-execution-prevention-explanation/

So it would appear that not enabling DEP using EMET for a specific application should not reduce your protection. However with Yahoo Messenger, it will reduce your protection since Yahoo Messenger does not support DEP (system-wide or using EMET) as shown in the following screenshot:

Direct Link to Image:

http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/YahooMsgDEPStatus_HL.png

I also mention how a previous version of EMET enables DEP for a process in the following thread (post dated 22nd March 2013):

http://social.technet.microsoft.com/Forums/security/en-US/51ebedf3-faf3-40a0-a2cc-00749b780f57/dep-broken-in-emet-35

I am unsure if this still applies for EMET 4.0.

I choose to set System-wide DEP to always on since a program can call the SetProcessDEPPolicy() function to disable DEP for that program but this technique does not work when System-wide DEP is set to always on. This is useful when a malicious DLL or shell code gets injected into a process and wants to make exploiting that process easier, if DEP cant be disabled, that job is made harder (not just for that process but for the system as a whole). You could argue that this is not gaining you any protection since if a DLL or shell code has been injected into a running process your system is already compromised but it should make further compromise more difficult.

AshleyST is right about the entries in EMETs list of protected/configured applications. This table is actually stored in the Windows Registry and is used by Windows when loading applications (EMET hooks the API used to launch programs so that Windows will always carry out this action). If a match is found to an application that is being loaded, EMET.dll or EMET64.dll is injected into that process while EMET_CE.dll or EMET_CE64.dll are injected into a compatible web browser to enable EMETs certificate pinning feature.

This table is located in the following key of the Windows registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EMET

Here is a small screenshot of some of the entries for my system:

Direct Link to Image:

http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/Regedit.png

The overhead of having unused entries in that table is negligible as AshleyST correctly points out.

How EMET protects the applications it has been configured to by the user is explained in the following YouTube video featuring Didier Stevens (at approximately 02:10 duration within this video):

http://www.youtube.com/watch?v=zDZWgsJFEp4

I hope the above info is of assistance to you. If I can provide any further clarification or assistance, please let me know. Enjoy the rest of your weekend.

Thank you.

Thanks for the extensive post James, very much appreciated.

I have one slight anomaly with my MS Money application. This is a pretty old application from Microsoft that is

no longer supported.

Running it on both a Vista Business 32-bit system and a Windows 7 Professional 32-bit system with EMET I see the following.

If I set EMET DEP to Always ON it fails with a DEP error. If I trace it, I see the C0000005 failure when an

attempt is made to execute code from the stack. The attempt is due to a call instruction to a location in the stack made from a dll.  This I can understand.

I then change EMET DEP to Application Opt-Out and re-boot. I have DEP checked for msmoney.exe in my application list but have Caller ID not checked. I start MS Money and it works fine.

If I check DEP through system properties it has the setting as "Turn on DEP for all programs and services except those I select" and I have none selected.  

If I look in Task Manager it says that MS Money is running with DEP enabled. Assuming that the DEP protection is propagated to all DLL's (from the .exe level protection), I would have expected the same error as that when DEP is Always ON. However, I never get a DEP related failure.

Hi AshleyST,

Thanks for your kind words. I wish I could create such extensive posts more often, my time/availability lately (and for the foreseeable future) is much more limited than it used to be.

From my understanding of the following link:

http://0xdabbad00.com/2012/12/07/dep-data-execution-prevention-explanation/

DEP will not propagate to all DLLs within that executable unless that those DLLs were compiled with the NXCOMPAT compiler flag (but those DLLs still benefit from DEP even if they dont support it once the .EXE file that loads those DLLs supports it). As you can see from Yahoo Messenger (above) all but one DLL were compiled without this flag. That is a major failing in my opinion since Instant Messaging applications are
frequent targets of malware and these compiler security options are the defaults unless they are then turned off. In the year 2013, that should be no reason to do that (unless your code is very old).

However you are correct, that link also mentions that if DEP is enabled for the .EXE, all DLLs that the .EXE file loads benefit from DEP too. The diagram shown at the end of that blog post sums it all up. The above blog post explains how DEP can apply to .EXE and DLLs better than I can :)

The Windows setting Turn on DEP for all programs and services except those I select" is rather confusing. This is equivalent to Application Opt-Out of DEP whereas Always On is just that, even if the application opts out it will still have DEP applied which will usually cause a crash.

I have found that with DEP set to Always On, the DEP settings of the Windows Control Panel are then grayed out since Windows does not allow a user to enable this option for DEP using the Control Panel. However this option is available using EMET or with the Command Prompt using the commands mentioned in the following Microsoft Support article:

http://support.microsoft.com/kb/875352

I originally mentioned this article in the following EMET thread:

http://social.technet.microsoft.com/Forums/security/en-US/ac54e1e4-d11b-4b24-9555-db889727d92d/windows-says-dep-is-opt-out-emet-35-says-its-opt-in

On my Windows 8 Pro 64 bit system, here is what the DEP settings of Windows look like when DEP is Always On. Its helpful that Windows makes reference to bcdedit to change that setting:

Direct Link to Image:

http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/Win8DEPAlwaysOn.png

Also the DEP setting of Windows 8 is not DLL aware (which is a technicality since .EXE and DLL files are both PE (Portable Executable) files with simply a different extension and a single bit difference in their file headers (the same applies to .OCX and .CPL files).

The fact that Windows does not support adding DLLs to the DEP exceptions lists hints at that it ignores DLLs with regards to DEP (but I could be wrong):

Direct Link to Image:

http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/Win8DEPNoDLLs.png

Note that DEP was set to Application Opt-Out in the second image.

It likely does this for performance and compatibility reasons. E.g. The Windows 7 and Windows 8 AppLocker feature can block individual DLLs from loading but there is a high performance impact in doing so. AppLocker is a powerful security feature of Windows 7 and Windows 8 that I use whenever I can. It is much easier and more flexible to configure than Software Restriction Polices.

As that support article mentions any applications on the exception list (if they are any) are ignored when DEP is AlwaysOn. From my understanding all code i.e. both .EXE and DLL files must support DEP when using this settings or else they will crash. DEP set to Application Opt-Out allows .EXE files to opt-out but is not DLL aware which would explain why MS Money continues to work even with DEP set to Application Opt-Out (even with no DEP exceptions set).

By the way, I agree with your observations and I am simply trying to provide more evidence why it works the way it does. Please feel free to correct me if I have misinterpreted any details.

Finally, may I ask an off-topic question?  In your previous post you mention a C0000005 failure. What tool did you use to detect this behavior? I am asking since it would be useful to know for any future posts that I may need to demo that behavior. Would Process Monitor, WinDbg or OllyDbg be used for this?

I would also like to thank you for your many contributions to this thread. Have a good day.

Once again James, thanks for finding the time for an extensive post. 

My observations regarding the DEP settings, on both Vista Business and Windows 7 Professional, are the

same as yours. If I set DEP to Always ON, the system properties is greyed out. If I set it to Application Opt-Out  then the system properties is left with the option of selecting application to exclude.

I think with MS Money what I'm seeing is the .exe IS being protected (it's DEP column is ticked in EMET AND

Task Manager says it's DEP enabled). However, I think as the DLL is not compiled with the correct options, it's not protected. 

To catch the C0000005 I used WinDBG. Obviously with DEP set to Always On, ALL storage allocations made

in the stack have the non-execute bit set in the corresponding page table entry. Therefore, ANY attempt to

execute from there will cause the exception (as detected by the hardware).

With DEP being done selectively, whether from the system properties or EMET, there is the possibility that storage is allocated in the stack with the corresponding page-table entry not having the NX bit set. This will allow code to execute from the page.

I'm more than happy with what EMET adds to my system protection, so having to tailor the MS Money application entry in EMET is fine by me.

I just wanted to come back and say thank you very much to both of you for helping me on my post. I don't have as much knowledge and experience on this subject as you two but from the research you did it seems like Yahoo Messenger wasn't coded with much security in mind. That's a neat tool "slopfinder", maybe one day I can figure out how to use it before installing programs. I'm just not sure how to extract all the contents to upload without installing the program first. Anyway thanks again for you two's help and hard work on this subject, hopefully Yahoo will update their code soon or I can find a better messenger program that works with EMET. 

Hello,

@AshleyST:

I think you are right about MS Money having its .EXE file protected by DEP. However since you have EMET v4.0 protecting MS Money, I agree you are more than safe enough. EMET v4.0 adds a significant layer of defence especially for 32 bit programs (64 bit programs do not make use of the ROP mitigations since EMET v4.0 does not apply them to 64 bit programs. The Users Guide of EMET v4.0 page 16 mentions this).

Thanks for the hint about using WinDbg, I will be sure to use it to good effect.

@bf-109:

You are more than welcome. I am glad that AshleyST and I could assist.

I dont know how to use Slopfinder either to extract the contents of a program installer without installing it first. This is exactly what I did. Once I had finished testing Yahoo Messenger, rather than uninstalling it; I created another virtual machine snapshot (in case I needed to continue testing Yahoo) and then reverted back to my previous snapshot and everything was just as I left it :)

If you have any other questions about EMET, please let us know.

Many thanks for marking AshleySTs and my posts as answering your question, it is much appreciated.

I hope that you both have a good day.