Troubleshooting an EMET Mitigation Application Crash


 

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:

  • Work with the developer of the application and see if they can make their application work properly with EMET’s mitigations
  • Create an exclusion for the mitigation which is causing the application to crash

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:

image

excel being closed because of a DEP check.  A few things to notice here quickly

  • This is an actual EMET sourced event
  • Because this is EMET source it probably means that this is the application DEP mitigation vs the system-wide DEP mitigation (which doesn’t cause an EMET event sourced EventID)

So the quick fix here is basically to go into EMET and uncheck DEP from Excel:

image

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 Smile ) 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:

  • You could completely uninstall EMET and test
  • This is a little bit overboard for just one application but it is one way to start
  • Keep in mind that uninstalling EMET may not return system-wide protections (DEP/SEHOP/ASLR) to their previous configurations so if the app is still crashing after an uninstall it may be due to those 3 system-wide settings
  • Target the application specifically.  This will require methodically working through mitigations to try to ascertain which mitigation(s) are the cause of the issue.
  • Uncheck the application wide mitigation settings one at a time first.  You will need to ensure you close and restart the problem application each time you make a change

image

    • If none of those work then work through removing the individual mitigations for the application in question one at a time (or try a bunch of them if you are more impatient and then work backwards)

image

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.

Comments (6)

  1. Anonymous says:

    Pingback from tag based on what is being viewed.global $page, $paged;wp_title( ‘|’, true, ‘right’ );// Add the blog name.bloginfo( ‘name’ );// Add the blog description for the home/front page.$site_description = get_bloginfo( ‘description’, ‘display’ );if ( $site_description && ( is_home() || is_front_page() ) )echo ” | $site_description”;// Add a page number if necessary:if ( $paged >= 2 || $page >= 2 )echo ‘ | ‘ . sprintf( __( ‘Page %s’, ‘twentyeleven’ ), max( $paged, $page ) );?>

  2. Anonymous says:

    Pingback from Blog Post: Troubleshooting an EMET Mitigation Application Crash | FlipsPops

  3. Rob says:

    Doesn’t managing Popular Software through Group policy make troubleshooting those apps even more difficult as the application will refresh the settings based on your GP refresh settings? I have a few systems where IE crashes and it is definitely EMET.
    Do we call MS to report this? What do they need in order to fix this?

  4. kjstech says:

    I never see Event ID 2 for EMET in application event log! My group policy has Reporting Enabled and it still does not write this kind of detail you have in your article.

    I see more vague information that does not even give me a clue what protection to take off. Here is a real life one:
    Log Name: Application
    Source: Application Error
    Date: 9/17/2015 11:28:30 AM
    Event ID: 1000
    Task Category: (100)
    Level: Error
    Keywords: Classic
    User: N/A
    Description:
    Faulting application name: OUTLOOK.EXE, version: 15.0.4745.1000, time stamp: 0x55a4b496
    Faulting module name: EMET.DLL, version: 5.2.0.1, time stamp: 0x5503c3e4
    Exception code: 0xc0000005
    Fault offset: 0x00063f82
    Faulting process id: 0x1f8c
    Faulting application start time: 0x01d0f15d817a5558
    Faulting application path: C:Program FilesMicrosoft Office 15RootOffice15OUTLOOK.EXE
    Faulting module path: C:WindowsAppPatchEMET.DLL
    Report Id: bf8f9cb8-5d50-11e5-ba04-f8bc12994b4b

  5. Kurt Falde says:

    Interesting as that’s not emet detecting and crashing but looks more like some interop issue w emet and outlook :( You could try taking off the mitigations’ a few at a time and seeing if a specific one fixes it. If not I would recommend opening a case
    w MSFT and see if we can figure out what’s happening.

  6. Casper says:

    Hi, I have an issue with our enterprise application AspenTech 8.8on Windows 8 x64, I expect that msxml 4 is the vulnerability, EMET is stopping msxml 4 via ASR in Internet Explorer. Although removing the ASR mitigation in EMET is not fixing the issue.
    Is there a way to redo this like DEP on OS lvl ?