we are seeing quite a number of reports on various support channels by users of the microsoft EMET tool which get constant "Bad news: This tab has crashed" messages after they have updated to Firefox 51. this seems to be constant and affecting all sites so it is rendering the browser pretty useless. no real crash report is generated and submitted for users in this situation either. according to feedback of one user, fiddling with the SEHOP option in emet helped...
Related to SEHOP, bug 599611.
tracking-firefox51: --- → ?
tracking-firefox52: --- → ?
tracking-firefox53: --- → ?
tracking-firefox54: --- → ?
Component: Other → General
Product: External Software Affecting Firefox → Core
See Also: → bug 599611
David, do you have time to look at this?
All of the reports with that tag have EMET.dll versions 2 through 4. I haven't seen a single 5.x in the mix, and the current 5.52 was fine for me locally at max settings. 5.0 was mid-2014 so the crashing versions are pretty old at this point. Microsoft's download links for those versions are now 404, so I wasn't able to debug locally. Do we have any way of informing people, short of case-by-case SUMO response, to upgrade or disable their EMET?
I hope we can deploy something through the new SHIELD system: that's exactly the kind of thing it's supposed to help with! Would you like to own following up with Matt Grimes, or do I need to?
If you could own that, that would be great!
We looked at this in regression triage today. Benjamin should this get an owner soon? Do you want to track this for 51?
Ben - do we have any sense of the impact of this bug? How popular is this tool do you think? I understand we lack precise data here, just want to have some idea.
I really don't know. I don't think I have any useful Firefox datasource for EMET in particular (the new modules ping will help!). It might be possible to detect that users were having a serious problem (content never starting up) by looking at the number of content process aborts versus childPayloads. But that would require some serious data-diving. Here's my not-very-educated hunches about EMET adoption: * It's probably fairly low, probably <1% of users total have any version of EMET * EMET is probably primarily employed by paranoid power users and by enterprise system administrators. Having an old version means either that it doesn't updates as part of Windows updates or the sysadmin didn't deploy any updates. I really don't know much about that. Again, those hunches are not backed by any data.
In bug 1337105 there's a crash report with an old version of EMET.
Benjamin, is there someone else who can follow up on this (for blocking with Shield or some other way to avoid the crash by blocking older versions of EMET)? Thanks.
tracking-firefox51: ? → +
tracking-firefox52: ? → +
At this point there is nothing SHIELD can do, and I doubt that our blocklist would do anything either. I don't think there is anything left to do here.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
OK, thanks. Wontfix for 51/52; if someone figures out a magical fix we could still take a patch up to 53.
status-firefox51: affected → wontfix
status-firefox52: ? → wontfix
status-firefox53: ? → fix-optional
status-firefox54: ? → fix-optional
tracking-firefox52: + → -
tracking-firefox53: ? → -
tracking-firefox54: ? → -
You need to log in before you can comment on or make changes to this bug.