Discussion in 'other anti-malware software' started by luciddream, Apr 1, 2013.
some software is impossible to use with caller enable, QQ chat is one of them.
Thanks for that bit of useless information.
Caller is enabled on a per-app basis, not globally. If Chrome isn't compatible with it, then it needs to be disabled...
Honestly don't understand what you're trying to say with that statement.
I was just trying to state that Caller catches by far the most exploits. If you disable it, many new exploits will no longer be blocked, severely impacting EMET's usefulness. I think disabling it on a browser like Chrome you might as well exclude EMET entirely from Chrome.
Alternatively you could also try a different exploit mitigation tool to protect Chrome, like MBAE or Alert.
Well you have ASLR, DEP....
Not sure why Chrome crashes when caller is active. Event viewer gives sparse information.
ASLR and DEP are passive mitigations. Most current exploits bypass ASLR and DEP via pointer disclosure or ROP attack. See also here:
That is why you need an active mitigation like Caller to actively block ROP attacks.
But again, if the app is not working with Caller mitigation, you have no choice but to disable it (or use an alternative).
Best is to contact the developer of the app and hope they can update their app to support EMET. Because if Caller is crashing the app, its probably the app is doing something extraordinary.
I can only assume you don't understand how EMET functions. By disabling Caller you don't loose anything, you simply haven't gained the mitigation, which is incompatible with Chrome. Everything you add in EMET is a gain, there is no loss whatsoever.
Why would I do that. All the other mitigations work just fine.
Thanks for the link. The fig shown in the blog gives an overview indicating that hackers seem to be shifting away from ASLR and DEP.
But didn't Google once indicate that EMET isn't necessary with Chrome? Perhaps they figure zero days are patched quickly and EMET doesn't fill any function there.
"We are in contact with Microsoft to investigate and address this problem, since the incompatibility is between code emitted by Microsoft’s compiler and a check in Microsoft’s security software. Microsoft currently is recommending that the EMET caller mitigation not be enabled for Chrome."
Oh, and if you encounter any strange crashes and suspect EMET, note this:
EMET 5.0 is the first EMET version that has Deep Hooks enabled by default. It was off in previous versions due to compatibility issues.
"EMET’s Deep Hooks capability helps protect the interactions between an application and the operating system. In EMET 5.0, Deep Hooks is turned on by default, helping provide stronger protections by default. Furthermore, this default setting is now compatible with a wider range of productivity, security and business software."
I can totally understand that. But on the other hand, tech savvy users probably think this is a good thing. At least I do. That EMET gets improved with every new version with new protection features, even if it gets more complicated to configure it. Well, luckily there are other products out there.
OT, I noticed that if you disable EAF+ or ASR (for testing purposes like I did) and it has additional settings(modules) defined, they are lost If you're not aware of that and you turn them on again, you're missing the extra modules protection. To find the default setting without importing an entire program list again, open the xml file, search for the program in question and look in the tags <eaf_modules> <asr_modules> <asr_zones>
Xml files: C:\Program Files\EMET 5.0\Deployment\Protection Profiles
This could explain the issues people are reporting here.
Thanks, a good find.
I'm perhaps also noticing that the combo EAF + Caller + Chrome don't work well. Tried enabling Caller and disabled EAF and, so far, no crashes.
With EMET 4.1 I enabled Deep Hooks and had no problems with Chrome.
I noticed this too and submitted a issue on the EMET Connect Portal https://connect.microsoft.com/emet/feedbackdetail/view/935027
May I know what to add into EMET's (version 5) additional protection for LibreOffice. I thought I just need to add the executables of the components (swriter.exe, scalc.exe, etc) into the list, but when I checked it was not protected by EMET. I only see soffice.exe and soffice.bin, and of course I can't add the BIN one, so I only added soffice.exe which is now protected by EMET. Is it still necessary to add more of LibreOffice's executables (swriter.exe, scalc.exe, etc) into the additional protection list? They don't seem to appear in the running processes list. I've tried to get myself some info but still got no definitive answer. Thanks for the help.
I've been using OpenOffice.org (and many of it's derivatives such as LibreOffice) since about 2002 on Windows specifically. From my understanding, the soffice.bin files works side by side with soffice.exe and does a lot of the workload in the background as well. So it's a bit unfortunate that you are unable to protect the BIN file as well. However, I'm sure any exploits would target soffice.exe first anyways. I'm pretty sure that the other individual program executables only run when started specifically from the Start menu anyways or desktop shortcuts but switch over to soffice.exe and soffice.bin briefly afterwards, so that could be why they are likely not showing as protected or possibly not even running after in task manager. I might install LibreOffice later tonight again just to test some of this EMET protection anyways because I haven't experimented that far with EMET yet aside from the more popular programs. Have you had to disable any mitigations with LibreOffice or any ill effects with EMET?
So far I don't see any noticeable breakages. But I left EAF+ and ASR disabled, just as their default settings.
I noticed emet 4.1 on a true windows admin account (where no UAC prompts) it wont run says admin priv needed. But it works on my LUA after entering the admin password, strange eh?
I have an EMET question. I have added Firefox. Do I need to add Plugin-Container.exe. Also what other applications do you add.
If you add firefox, Plugin-Container.exe or any other such child processes will automatically be protected whether you manually add them or not. I add browsers, pdf reader, media players, IMs and office. That should be enough. Of course if you use java add that too.
Open EMET and simply click Import in the top left corner, which will show default config files as tested by Microsoft.
Likely stored in this location:
C:\Program Files (x86)\EMET 5.0\Deployment\Protection Profiles
Choose Popular Software.xml and that with import the proper settings for most common popular software and also includes plugin-container.exe for both Firefox and Thunderbird. Also enables EAF+ to give extra protection to Firefox's mozjs.dll and xul.dll modules.
Also protects Adobe products, Oracle Java, Apple products, 7-Zip, and so on.
C:\Program Files (x86)\EMET 5.0\Deployment\Protection Profiles
Does anyone have recommended settings to make Chrome work with EMET 5.0. I just installed Chrome, and EMET. I'm giving them both a trial run. I was able to get Firefox working with EMET, but EMET is still causing Chrome to time out when trying to go to any webpage. I have already disabled EAF which allowed Chrome to launch.
Are you using Chrome's built-in PPAPI Flash Player or NPAPI Flash Player?
I personally haven't had to disable any mitigations with Chrome 64-bit on Windows 7 SP1 64-bit running EMET 5.0 and no ill effects whatsoever. But everybody has different browser configurations, whether using Firefox or Chrome, different plugins, extensions, add-ons, etc. that I believe could play a role in some of these issues that I've seen reported with Chrome and EMET 5.0 so far. Different web sites too with different functionalities, of course. Anyways, getting to the point, I've seen a few people mentioning about having to disable mitigations for SEHOP and/or Caller with EMET 5.0 and Chrome. You could also try unchecking Deep Hooks as well. Although remember to restart Chrome after each change to see if it helps, also ensure that chrome.exe isn't running in task manager between settings changes because sometimes there are certain circumstances in which chrome.exe stays running even after closing Chrome.
There was a recent blog post by one of the EMET devs that had details about diagnosing problems with applications that might conflict with certain mitigations that would be quite helpful but I can't find it at the moment. I will post the link if I find it again. Basically it just detailed unchecking one mitigation at a time, restarting the app (Chrome, in your case) and keep doing that until the specific mitigation causing problems is found, then recheck the others that were not an issue.
EDIT: Found the link.
Troubleshooting an EMET Mitigation Application Crash:
Thank you for your help! EMET blocked Chrome from even launching at first so I unchecked EAF, and that resolved that issue. Then I tried using Chrome to surf the web, but every single page I visited timed out. I then disabled Caller because I read it was causing problems with Chrome for someone else. That did not resolve my problem with all webpages timing out. I will try SEHOP next as you suggested, and keep playing process of elimination until I find out which one is causing the problem. Hopefully i will not be more than one because if it is then I would have to uncheck all of them, and add back one at a time until I figure out which ones are causing the problem. I'm using the following plugins: Adblock Plus, ScriptSafe, and a plugin that shows the flag of the country hosting the website. I can't remember what the plugin is called, and EMET is blocking me from seeing the plugin. EMET is blocking me from accessing the settings. Thanks for your recommendation. I will try it now.
That makes it a little tricky since you can't access the Chrome settings and extensions/plugins. What I would try in that unique case would be to temporarily disable all mitigations on Chrome so that EMET is not protecting Chrome at the moment, restart Chrome and you should at least be able to access the settings for extensions and so on. You could maybe start by disabling your extensions/plugins so that Chrome is running bare bones. Then enable all mitigations on Chrome in EMET again, restart Chrome again and see if it behaves any better. Kill EAF again if it prevents it from starting. See where it goes from there. That's just another way to look at it, maybe rule out if it's an extension or plugin that's not playing nicely with certain mitigations.
An important question. Do you have AppGuard or any HIPS running as well? Basically any other security software that might be injecting dlls or hooks into the chrome.exe process. It's quite possible that if that was the case there could be conflicts with that for sure. That would be almost guaranteed to cause problems.
I figured it out. The following has to be unticked in order for Chrome to work on my machine (Windows 7X64 Ultimate). EAF, Caller, SimExeFlow, and StackPivot. If any of those are ticked then Chrome will not work on my machine. Chrome is working fine now. Thank you!
You're welcome, always happy to help. It's unfortunate that you've had to disable so many mitigations. But I'm glad Chrome is working well now. Also, I remember a recent EMET blog stating how each single mitigation i capable of stopping so many different exploits, plus Chrome has such good security anyways so you should have no worries now.
Separate names with a comma.