In the process of deploying and piloting EMET there is a definite possibility that a legitimate application will not function properly with EMET.
Lets try to set some expectations here there are basically 2 things you can do when this occurs:
That’s pretty much it. You could call MS support and we could walk you through the troubleshooting process however typically when an application crashes with EMET it’s because that applications behavior is matching with something that EMET does not like.
From an IT Admin perspective you pretty much have to treat this like an AV Exclusion type of ordeal. Put the exclusion in now, get the LOB application working again and then longer term try to see if the application owner/developer can remediate.
So for example an example of an application being closed by EMET lets look at the below:
excel being closed because of a DEP check. A few things to notice here quickly
So the quick fix here is basically to go into EMET and uncheck DEP from Excel:
So the Security expert in you just said BUT, BUT… I just left a hole open now by removing a protection that might have stopped some exploit… And you are absolutely right. Keep in mind though that you still have ~14 more memory corruption mitigations that are still enabled for Excel so it’s not a complete loss you are still way better than not using EMET. Also while removing that mitigation is the tactical solution to get your Excel working again the longer term fix would be in this case to open up a case with the application owner (Excel = Microsoft ) and we could see about contacting the Excel support team to see what they have to say about it. Keep in mind if this was some other application you would want to contact that vendor.
Another good thing to keep in mind is that many times there are multiple mitigations that on their own will stop a specific exploit. The recent IE vulnerability is a great example of this. If you view the EMET Teams blog at http://blogs.technet.com/b/srd/archive/2014/04/30/protection-strategies-for-the-security-advisory-2963983-ie-0day.aspx you can see their chart on which mitigations were effective at stopping the exploit. So on it’s own HeapSpray would stop it or StackPivot (w Deep Hooks enabled) or Caller ROP (w Deep Hooks enabled) or MemProt (w Deep Hooks enabled) etc.. so you could have had StackPivot disabled due to some LOB application not working with StackPivot but any of the other mitigations still be effective at blocking that piece of exploit code.
Now if you have some application that is crashing and you believe it is EMET caused but no events for it here are some steps to take to troubleshoot:
That “should” be it in most cases you will eventually discover the issue and be able to create the proper exclusions to allow the application to work in your environment.
If you have any questions please leave them in the comments below and I will do my best to answer.