locked
EMET 5.0 + Internet Explorer 11 consistently detects Caller mitigation on seemingly random workstations RRS feed

  • Question

  • There seems to be no rhyme nor reason why a particular system is effected. Error observed on fully-patched clients across Win 7 Pro and Enterprise, all x64. This is using the default protection rule for Internet Explorer from the group policy settings for EMET 5.0.

    First event log records this:

    Log Name:      Application
    Source:        EMET
    Date:          10/23/2014 3:27:50 PM
    Event ID:      2
    Task Category: None
    Level:         Error
    Keywords:      Classic
    User:          N/A
    Computer:      <omitted>
    Description:
    EMET detected Caller mitigation and will close the application: IEXPLORE.EXE

    Caller check failed:
      Application     : C:\Program Files (x86)\Internet Explorer\IEXPLORE.EXE
      User Name     : <omitted>
      Session ID     : 1
      PID         : 0xCEC (3308)
      TID         : 0x10F0 (4336)
      API Name     : kernel32.LoadLibraryExW
      ReturnAddress     : 0x7435A171
      CalledAddress     : 0x74B74925
      TargetAddress     : 0x74354F30
      StackPtr     : 0x0043F328

    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="EMET" />
        <EventID Qualifiers="0">2</EventID>
        <Level>2</Level>
        <Task>0</Task>
        <Keywords>0x80000000000000</Keywords>
        <TimeCreated SystemTime="2014-10-23T20:27:50.000000000Z" />
        <EventRecordID>59324</EventRecordID>
        <Channel>Application</Channel>
        <Computer><omitted></Computer>
        <Security />
      </System>
      <EventData>
        <Data>EMET detected Caller mitigation and will close the application: IEXPLORE.EXE

    Caller check failed:
      Application     : C:\Program Files (x86)\Internet Explorer\IEXPLORE.EXE
      User Name     : <omitted>
      Session ID     : 1
      PID         : 0xCEC (3308)
      TID         : 0x10F0 (4336)
      API Name     : kernel32.LoadLibraryExW
      ReturnAddress     : 0x7435A171
      CalledAddress     : 0x74B74925
      TargetAddress     : 0x74354F30
      StackPtr     : 0x0043F328
    </Data>
      </EventData>
    </Event>

    Then the following event will be recorded:

    Log Name:      Application
    Source:        Application Error
    Date:          10/23/2014 3:27:50 PM
    Event ID:      1000
    Task Category: (100)
    Level:         Error
    Keywords:      Classic
    User:          N/A
    Computer:      <omitted>
    Description:
    Faulting application name: IEXPLORE.EXE, version: 11.0.9600.17344, time stamp: 0x541b6f63
    Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
    Exception code: 0xc000001d
    Fault offset: 0x00000000
    Faulting process id: 0xcec
    Faulting application start time: 0x01cfeeffd0e17a00
    Faulting application path: C:\Program Files (x86)\Internet Explorer\IEXPLORE.EXE
    Faulting module path: unknown
    Report Id: 0ea594ca-5af3-11e4-b2b7-047d7bb9c5ad
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Application Error" />
        <EventID Qualifiers="0">1000</EventID>
        <Level>2</Level>
        <Task>100</Task>
        <Keywords>0x80000000000000</Keywords>
        <TimeCreated SystemTime="2014-10-23T20:27:50.000000000Z" />
        <EventRecordID>59325</EventRecordID>
        <Channel>Application</Channel>
        <Computer><omitted></Computer>
        <Security />
      </System>
      <EventData>
        <Data>IEXPLORE.EXE</Data>
        <Data>11.0.9600.17344</Data>
        <Data>541b6f63</Data>
        <Data>unknown</Data>
        <Data>0.0.0.0</Data>
        <Data>00000000</Data>
        <Data>c000001d</Data>
        <Data>00000000</Data>
        <Data>cec</Data>
        <Data>01cfeeffd0e17a00</Data>
        <Data>C:\Program Files (x86)\Internet Explorer\IEXPLORE.EXE</Data>
        <Data>unknown</Data>
        <Data>0ea594ca-5af3-11e4-b2b7-047d7bb9c5ad</Data>
      </EventData>
    </Event>


    born to learn!

    Friday, October 24, 2014 12:38 PM

Answers

  • So... if you have Sophos clients that decide they don't want to obey policy that disables Sophos' buffer overflow protections - you will see this problem!

    Mystery resolved - I had several Sophos clients that decided to not obey their BOPS policy from the server. This has been an ongoing problem with Sophos.


    born to learn!

    • Marked as answer by AJM Admin Friday, October 24, 2014 3:52 PM
    Friday, October 24, 2014 3:52 PM

All replies

  • We're seeing the same thing.  It started late last night / this morning.  It seems to be affecting PCs with EMET 4.1U1 and EMET 5.  I help manage multiple companies with separate AD forests and this is affecting them all.  So far we can't figure out what has changed.  No patches were applied.  
    Friday, October 24, 2014 1:43 PM
  • Our company experienced the exact same problem this morning. Had to disable Caller Mitigation in Group Policy and then refresh EMET on the workstations. Clearly this is a problem affecting everyone but what could have caused this to happen overnight? No changes had been made to IE, EMET or group policy on our end.
    Friday, October 24, 2014 3:02 PM
  • So... if you have Sophos clients that decide they don't want to obey policy that disables Sophos' buffer overflow protections - you will see this problem!

    Mystery resolved - I had several Sophos clients that decided to not obey their BOPS policy from the server. This has been an ongoing problem with Sophos.


    born to learn!

    • Marked as answer by AJM Admin Friday, October 24, 2014 3:52 PM
    Friday, October 24, 2014 3:52 PM
  • Hey smeade, do you happen to be using Symantec Endpoint Protection 12.1 as we are? I'm developing a theory as to why this occurred, wanted to see if SEP is the common culprit.
    Friday, October 24, 2014 8:35 PM
  • Yes nu_husker, we're running SEP 12.1.4 although I uninstalled it on one workstation before I disabled the IE mitigations as a workaround and didn't seem to fix it.  More testing today...
    Monday, October 27, 2014 12:05 PM
  • BTW, what's your SEP theory?
    • Proposed as answer by nu_husker Monday, October 27, 2014 12:45 PM
    • Unproposed as answer by nu_husker Monday, October 27, 2014 12:45 PM
    Monday, October 27, 2014 12:05 PM
  • Don't know if you were aware but Symantec has been planning on implementing a new Browser Protection engine for SEP. It disables the Symantec Vulnerability Protection add-on in Internet Explorer (and removes the Symantec add-on in Firefox). Symantec had been planning the update in September but it kept getting pushed back. This update was to be pushed through LiveUpdate and didn't need to be approved by the local administrator.  You can see the TID here: New Features in Client Intrusion Detection System (CIDS) 14.1, http://www.symantec.com/business/support/index?page=content&id=TECH224237&actp=SUBSCRIPTION

    On Friday when this issue occurred for both our sites Symantec published the following TID: Internet Explorer hang or machine freeze after CIDS update 10/23/2014 r12, http://www.symantec.com/business/support/index?page=content&id=TECH225736&actp=SUBSCRIPTION.  Although this particular issue didn't affect us it did clue me in that the new CIDS had been pushed out.  I looked on a couple different PCs and confirmed the the IE Add-on had been disabled.

    So the fact that the only changes made to our PCs between Thursday & Friday would have been SEP definitions I have to conclude it is the new SEP Client Intrustion Detection System that caused EMET to flag Internet Explorer with Caller Mitigation.

    • Proposed as answer by smeade Monday, October 27, 2014 1:46 PM
    Monday, October 27, 2014 12:58 PM
  • I'll have to investigate this in IE.  Uninstalling SEP doesn't fix the issue so maybe it's a plugin.  Of course it's difficult to check when IE crashes every time you open it 
    Monday, October 27, 2014 1:28 PM
  • I'm still having the problem with SEP completely uninstalled and running IE in safemode.  I don't see any Symantec related plugins installed.  So either it's not SEP related, or they've really got their hooks deep into IE and their uninstaller is still crappy.
    Monday, October 27, 2014 1:46 PM
  • I fixed our problem by disabling Caller Mitigation for Internet Explorer in EMET via Group Policy.  It was easier than messing with SEP.  Here's the info on disabling CIDS in SEP.  I haven't tried this.

    Disabling CIDS by policy
        Login to the Symantec Endpoint Protection Manager (SEPM).
        Click Policies>Intrusion Prevention and Double click the Intrusion Prevention policy used by the clients you wish to disable CIDS on.
        Click on Settings.
        Uncheck Enable Network Intrusion Prevention.

        Note: On SEP 12.1 and higher, you can optionally disable Browser Intrusion Prevention by unchecking Enable Browser Intrusion Prevention.
        Click OK to save the policy changes.

     
    Manually disabling CIDS on the client
        Open the Symantec Endpoint Protection client interface.
        Click Change Settings.
        Click Configure Settings in the Network Threat Protection section.
        Uncheck Enable Network Intrusion Prevention.

        Note: On SEP 12.1 and higher, you can optionally disable Browser Intrusion Prevention by unchecking Enable Browser Intrusion Prevention.
        Click OK.

    Monday, October 27, 2014 2:26 PM
  • I've also disabled the Caller Mitigation for IE on our cilents for now, but I'm still trying to figure out the root cause of this.  I ran the latest version of Symantec's cleanwipe tool and rebooted and that still didn't fix the issue with the EMET Caller Mitigation turned on.  I'll have to reinstall and then try disabling it from the SEP policy and see if that does anything.
    Monday, October 27, 2014 2:36 PM