There should not be exploits blocked by EMET when updating Chrome. Either EMET is blocking something harmless or your computer has malware. Your EMET log is empty (0 bytes) so I would assume you have malware.

This happens since the last stable build of Chrome (53.0.2785.89). EMET kills every browser addon causing chrome to display a crash message for each addon in an endless loop of messages by chrome (Addon crashed) and EMET (detected EAF+ (GuardPage) mitigation).

A workaround is to deactivate the EAF+ rule for Chrome in EMET. Older versions of Chrome (a few years back) had the same problem.

I also got some crash IDs for you devs:

a5b4e66f-9b65-4332-a343-be5d6fd49925
3447e2b8-d29d-4bd7-b97e-28c3b1075f3d
187fcd91-57d7-4135-bdd0-36eae8ea065c 
91e301ea-e94f-4cc6-bbee-2c32e8b6f5a0
385d710f-83dc-427c-9a21-3ebb3eee9758 
82eb0165-8a02-407f-8b9b-576edcf3da8e
94eec7a9-d13b-4558-aede-de8410cb45a8

Chrome is literally spamming crashes because it tries to reload.


This is what an eventvwr entry by EMET related to the problem looks like:

EMET version 5.51.6024.23768
EMET detected EAF+ (GuardPage) mitigation and will close the application: chrome.exe

EAF+ (guard page) check failed:
  Application 	: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
  User Name 	: XXXXXXXXXX\XXXXXXX
  Session ID 	: 2
  PID 		: 0x1A0C (6668)
  TID 		: 0x143C (5180)
  Module 	: chrome_child.dll
  Mod Base 	: 0x00007FFEB3EB0000
  Mod Address 	: 0x00007FFEB466DA19
  Mem Address 	: 0x00007FFEB3EB01C8

Hope this helps.

Hi chrome Team.
Thanks for the update and prompt response. As a workaround I have
uninstalled EMET 5.5. I was aware about the EMET EAF+ and caller. We are
going to create a GPO to exclude it.

Thanks.

El sept. 4, 2016 1:42 PM, "fi… via monorail" <
monorail+v2.3780762340@chromium.org> escribió:

Can you run a scan with the Chrome Cleanup Tool and Malwarebytes Anti-Malware?

Hello, those exploits are imho not being blocked due to malicious software (scan reports are clean btw). You can clearly reproduce this problem by updating to the current stable build (53.0.2785.89).
The old stable (52.0.2743.116) version is not affected. I can reproduce this on my Windows 10 Workstation and on my testing VMs running Windows 10.
The cause is likely either a change introduced into the code or a problem in the building/compile-toolchain for Windows.

Then this would probably be an EMET false positive which you could report to Microsoft. I extremely doubt that there is something in Chrome that should be blocked by an anti-exploit application when doing nothing but updating.

It is actually not the update process itself, but any instance of the new version which crashes. Step one from the reporter is a bit misleading, but step two makes clear that the new chrome version itself has this problem.

Another thing is that there is no thing such as a false-positive with EMET. EMET is not an antivirus engine. It just detects various behaviour which is commonly used by exploits in order to execute code etc.
Depending on how you have written your application you may trigger EMET, but rather through weird memory management, weird dynamic function calls, etc. Chromes devs will have to take a look at what cause of this behaviour is. Until then you can only disable EAF+ Mitigation or wait for Microsoft to work around this which I think will take longer.

Please note that there's some known compatibility issues between EMET and Chrome and so we recommend to not use it on Chrome: https://www.chromium.org/Home/chromium-security/chromium-and-emet

Chromium team,

thanks for the updates. I have uninstalled EMET to completely avoid issues
with Chrome.

You can close the case.

Thanks,

2016-09-06 14:30 GMT-03:00 sebmarch… via monorail <
monorail+v2.1670070753@chromium.org>:

Please note that we don't recommend that you uninstall EMET (it's up to you to decide if you want to use it or not), our only recommendation is to not use it on Chrome.

Thanks

Ok,

so I am going to install EMET again and clear EAF+ setting to avoid
compatibility issues.

2016-09-06 14:48 GMT-03:00 sebmarch… via monorail <
monorail+v2.1670070753@chromium.org>:

The linked Chromium/EMET page refers specifically to a much older version of Chromium and the Caller mitigation setting.  Do you have any further information about what exactly is causing Chromium 53 to trip EAF+, and why it is ONLY the 64-bit version that is tripping this mitigation in EMET?
Thanks!

We're investigating on this, this is a bad interaction between EMET and some compiler features that we're using on Chrome 64 bits (PGO).

Just updated Chrome and now I get the EMET trigger and chrome death. Please fix. This is just the latest version, was working great until I updated. I have EMET set with Group Policy (as I am sure a lot of corporate users do) and can only temporarily work around the issue with EMET settings.

I also get the endless crash loop of plugins: 

"This happens since the last stable build of Chrome (53.0.2785.89). EMET kills every browser addon causing chrome to display a crash message for each addon in an endless loop of messages by chrome (Addon crashed) and EMET (detected EAF+ (GuardPage) mitigation)"

Why is this closed?

Would someone please share the reasoning behind "WontFix".

It's something out of our control, it's an incompatibility issue when using the EAF+ mitigation offered by EMET on Chrome, this isn't a real security issue.

Sounded like you are using some new compiler features. What changed between 53.0.2785.89 and the previous version? Can you just go back to the compiler features you were using before?

This is a huge issue. We removed 64-bit Chrome from 100k machines this week at my enterprise alone. Increasing risk by reducing EMET mitigations is not an option.

So the recommendation is for enterprises to remove the EAF+ mitigation from Chrome, then any future exploits that would have been blocked are then allowed and it does become a security issue?  Or do you hold an unsubstantiated claim that no one could write such an exploit against Chrome so there is no real reason to be concerned?.  Or perhaps you can recommend a sand-boxing tool in place of EMET that could encapsulate Chrome while the mitigations have to be disabled.  Or is the recommendation that we disallow our end users choice and forcibly remove Chrome from all enterprise end-points?  In any case our InfoSec and Cyber teams view the removal of EMET mitigations as opening a door for exploits. 

The protections that EMET provides are already in place internally in Chrome, and we have a history of pushing new security mitigations before tools like EMET. We've actually had compatibility problems with EMET since about M35 (back in 2013), and both our and Microsoft's recommended course of action is to disable EMET mitigations for Chrome.

https://www.chromium.org/Home/chromium-security/chromium-and-emet

Can you reference where that recommendation comes from Microsoft? I cannot find it anywhere other than from Chromium.

They mention disabling SEHOP at this site:

https://support.microsoft.com/en-ca/kb/2909257

This recommendation came from the last time we encountered and EMET incompatibility like this. No mention is made of EAF+, but we're reaching out to them to change this.

I'm closing comments because we already know exactly what's going on here and I don't see further feedback being productive. However, I think there's some very important context that is missing.

First, it's very important to understand that the EAF+ mitigation in EMET is conflicting with a common optimization produced by Microsoft's own compiler. So, if you really want EMET to work, then you need to reach out to Microsoft and ask them to make EMET compatible with their own compiler.

That stated, there's no real security value in employing EMET against Chrome. And the EAF+ mitigation in particular is relatively easy to bypass, so it works only if the exploit developer is ignorant of it. That's why we strongly discourage people from applying EMET to Chrome. Because Chrome already enables any mitigations that add genuine security value, and the remaining ones in EMET are generally compatibility landmines that don't improve security.