EMET and Deepguard compatibility?
The latest version of EMET, 5.0, was the most difficult one to configure to get all protected programs from the standard import file to work without crashing. A lot of trial-and-error with configuring the mitigations on every protected program. First I thought EMET didn't work well on all systems but now I've discovered that it's conflicting with Deepguard, and that's probably what's causing most of these crashes. Users that have certain other AV software have no problems.
The only solution is to enable the compatibility mode for Deepguard so it doesn't inject itself into processes. But I don't want to do that. What I would like is to exclude only certain processes, for example trusted ones like browsers, and to only use EMET on those. Without having to disable critical EMET mitigations because of Deepguard.
On all other processes I want Deepguard injections.
- Is this possible to do perhaps with a settings file? Or suitable as a future feature?
- Does F-Secure do tests with EMET, and if so can you share the results?
The mitigations that often are incompatible are EAF and StackPivot. Two of the most important mitigations in EMET as I understand it. I now have these disabled on several programs, but maybe it would be better to disable the Deepguard injection and enable these in EMET?!
A comment from F-Secure please.
Comments
-
Hello Nikk,
Unfortunately we haven't tested the latest version of EMET and its compatibility with our DeepGuard. However, I will report this to our DeepGuard team, so that they can do the testing.
Currently, if you want to use EMET with all of its features, you need to add file exclusions to F-Secure Anti-Virus settings to exclude those specific applications.
To exclude a file, please refer to following article:
http://community.f-secure.com/t5/Security-for-PC/How-do-I-exclude-a-file-or/ta-p/15398 -
-
Hello NikK,
Actually, if using compatibility mode helps with the problem, it would be preferred and also more convenient workaround compared to excluding files from scanning.
Regarding the article, the note was pointing to excluding file types, not object exclusion. Now the wording in that article has been changed.
-
Thanks. So there's no way of keeping the DeepGuard injections and exclude it only for some programs? Like excluding files from scanning but for DeepGuard injection instead. That's what I prefer. I don't like having to disable ALL DeepGuard injections just because a few of them are incompatible with EMET.
BTW, a new EMET version was released today, 5.1. I've tested it and it's better than 5.0. I can now have StackPivot enabled for all programs, but in order to enable EAF for some programs I have to enable the compatibility mode for DeepGuard.
I guess I was among the first to try 5.1 cause emet_gui.exe was automatically added as allowed in the "Monitored Applications", and EMET is usually a trusted program never seen in that list.
So in EMET 5.1 only EAF is incompatible with DeepGuard.
http://blogs.technet.com/b/srd/archive/2014/11/10/emet-5-1-is-available.aspx
-
Hi, I'm interested on this topic as well, as when using EMET 5.1 most applications crash due to Deepguard.
Microsoft already did a good job by pre-configuring EMET to disable certain mitigations for certain apps that are not fully compatible with all mitigations (example disabling EAF for Skype, ASR for Chrome, etc).
F-Secure seems quite restrictive in this sense, and doesn't allow fine grain control over Deepguard. It's either all or nothing. For the "compatibility mode" in Deepguard there should be some other option to choose specifically which app or process to run in this mode. It's good to have full Deepguard protection enabled for new malware and exploits, but this shouldn't lower the overall system protection just because few apps require "compatibility mode" (moreover when the problem is not with the apps, but with F-Secure's injection causing the compatibility issues!).
Hope this is at least being investigated. Learn from Microsoft EMET and allow us more control over the process injections in Deepguard! -
Hello,
Sorry for my reply... just because not really friendly with EAF as feature-protection. And with any developers-things. But how I can to understand... here also can be next points around:
-> EAF can be without troubles with DeepGuard (as compatibility).... if F-Secure and Microsoft have contact about this situation. Such as... EAF-feature prevent any "untrusted" actions by "untrusted" applications/modules/processes. Such as.... DeepGuard here as "something suspicious" and not whitelisted (if it possible there).
-> Crashes of software can be strange... but normal... because EAF should to work with that meanings maybe?! Such as.... process launched with modification.. and EAF should to protect against that. And anyway here comes something related with EAT, which marked as "wrong"... and current wrong related with DeepGuard injections. But probably here possible to allow current changes by EMET... or something like that?!
And maybe just because previously... here was another situation.
Maybe current trouble related with fixed status for vulnerables, which was detected under EMET mechanism for EAF/protection-for-EAT-work. And maybe here just already DeepGuard team can to think.. if they have something specific.. which goes to be not really compatibility with current fix-points.
-
Hello everyone and thank you for your feedback!
In F-Secure Labs where Deep Guard is being developed many of us run EMET and we are well-aware of the compatibility issues. We are currently working together with Microsoft to get those sorted out.
We had similar issue with EMET 4.0 and Microsoft was able to fix the problem at their side for 4.1 Update 1. Hopefully we can sort this out faster than last time.
Currently we are only aware of one issue and this affects EAF mitigation. We know the root cause and we have today informed Microsoft about it. We will keep you posted.
-
A quick note. The best way to solve this problem while we are waiting for the proper fix from MS is to exclude the affected executable file from on-access scanning in our product. This will prevent our user-mode hook installation shell code from running for the particular process and thus prevents EAF mitigation from triggering. This way Deep Guard can still utilize its full potential with other processes that are not being protected by EMET.
@Jouni already posted the link about how exclusions can be added. Please remember that you must set the real-time scanning exclusion.
-
That is very good news, thank you @Kimmo And also for describing the exclude process to keep DeepGuard injections for all other files. That's exactly what I wanted to know. Tested & approved
As I mentioned before, in EMET 5.1 only EAF seem to be the problem. In 5.0 StackPivot was also a problem but I don't know if the reason for that was EMET, DeepGuard, or perhaps both.
Tip: When EAF is enabled for Firefox it's extremely slow to start. To fix it go to EAF+ setting and delete xul.dll from "Modules". That file is 25 MB and probably explains why it's slow, but I'm not sure how it impacts the protection.
-
-
EMET 5.2 released: http://blogs.technet.com/b/srd/archive/2015/03/12/emet-5-2-is-available.aspx
It seems you still have to exclude EMET protected programs from the F-Secure real-time(on-access) scan, or EMET will detect EAF mitigation. Let's hope the conflicts between EMET and F-Secure work better in the next EMET release
Note: In the F-Secure settings this means the exclusion list under setting "Virus Protection" which should not be confused with the other exclusion list under "Manual scanning".
-
NikK schrieb:
[SNIP]It seems you still have to exclude EMET protected programs from the F-Secure real-time(on-access) scan, or EMET will detect EAF mitigation.
[SNIP]
Is this really the case with EMET 5.2 - and: only if EAF+ is activated or also with EAF?
Thank you and greetings!
Alpengreis -
I think it's only for EAF. The few programs that have EAF+ enabled also has EAF enabled. I use the program list and settings from EMET's Popular Software.xml and I have to exclude these files from F-Secure real-time scan:
"c:\program files\mozilla firefox\firefox.exe"
"c:\program files\mozilla firefox\plugin-container.exe"
"c:\program files\microsoft office 15\root\office15\outlook.exe"
"c:\program files\microsoft office 15\root\office15\winword.exe"
"c:\program files\microsoft office 15\root\office15\msaccess.exe"
"c:\program files\adobe\reader 11.0\reader\acrord32.exe"
"c:\windows\system32\macromed\flash\flashplayerplugin*.exe" (added by me. Not included in Popular Software list)
"c:\program files\windows nt\accessories\wordpad.exe"
"c:\program files\internet explorer\iexplore.exe"
There may be others you need to exclude too. I don't use a lot of programs from the Popular Software list for example Java, Google programs, Cloud programs, P2P programs etc.
For Office 15(2013) I have to exclude Outlook, Word, Access. But for example not Excel that also has EAF enabled. For some reason the fshook isn't injected into Excel. Don't know why.
Windows 7, 32-bit
-
-
I can't say for sure, don't know if anyone can?!
I believe the most important mitigation in EMET is ROP Caller check. EAF is perhaps not as important but still good(although both EAF and EAF+ have been bypassed by security people). I prefer EMET fully configured and enabled as I don't really know how good FS is at blocking exploits.
Remember that these FS exclusions are temporary and we're waiting for the compatibility problems with EMET to be resolved. The ideal solution is to have a full EMET configuration without any FS excludes.
I haven't seen any recent exploit tests that F-Secure was part of. Last year an independent test issued by Malwarebytes also compared common AV products against exploit kits but unfortunately F-Secure was not one of them. EMET 4.1 got a 74% detection rate but looking closer it only failed on Java based exploits. So if you exclude the Java exploits then EMET did much better than the rest. Only EMET and MBAE would be 100% without Java.
Here's the conclusion from "defeating EMET 5.2" (link below):
EMET fights tough, more than any public exploit mitigation solution out there. A lot tougher than MBAE and enterprise exploit detection products. But if we get to study the system, its only a matter of time.http://downloads.malwarebytes.org/asset/RCEMitigations.pdf
https://www.offensive-security.com/vulndev/disarming-and-bypassing-emet-5-1/
http://casual-scrutiny.blogspot.in/2015/03/defeating-emet-52.html -
