EMET (Enhanced Mitigation Experience Toolkit)

Microsoft EMET 5 review - Familiar goodness

 

Yes, it's fixed, I checked

I meant "am I protected from these kinds of attacks?" I guess it won't be easy to get a simple answer for this but at least you too seem to think what I'm thinking: that this is a new EMET feature to try and block this.

In the announcement of 5.0 TP there's a screenshot from where with only EAF+ enabled for IE, a Flash exploit was blocked. That surely looks great also for FF zero-days, but raised another question:
- Is there no need for a similar EAF+ module for the Flash version of FF - NPSWF*.dll? I can't see it either for Firefox or the plugin-container.

 

NPSWF*.dll doesn't run within firefox.exe process, just within plugin-container.exe and FlashPlayerPlugin*.exe as well. Whether adding it to EAF+ modules would/could be beneficial is anyone's guess. It might prevent future exploits or it might just cause performance issues. I tested it by adding 'NPSWF64_15_0_0_223.dll;NPSWF32_15_0_0_223.dll' to EAF+ out of curiosity and Firefox still worked well with Flash. But I would rather go with settings that the EMET dev team has tested since they have a better understanding. I guess it also comes down to whether or not exploits have targeted Firefox memory through this specific route or not.

 

You're probably right, but I've always wondered if the EMET people work a little harder when it comes to protecting MS apps, like with ASR. And the iexplore.exe EAF+ modules is another example, or maybe it's just a coincidence that iexplore has the most modules predefined, or it could simply be the fact that it needs more protection than other browsers?!

 

Actually, you know what, you are probably right on this. It makes sense that EMET dev team's first priority would be regarding the security and compatibility of MS software. And they probably wouldn't put too much time into other open source programs (or just other programs in general) and likely wouldn't dig too far into them since that would require research, time, etc. Maybe some of us here on Wilders can dig into it more and do some testing. I am up for doing some testing, anytime.

The only issue for me is that I don't know as much when it comes to where to look for exploit information for specific programs, and more specifically to find out which of those .dll/plugins/etc are being used to exploit within that program's process. I wish that there was an easy way to see how many instances of a certain .dll/plugin/etc being used to exploit within that running program process to get an understanding of what is more prevalent which would help us prioritize which modules to protect/test first. Obviously this could start with Firefox and we could move on to other software as well.

 

Wouldn't it be better if MS included this mitigations in their software, so there would be no EMET needed to protect their software? Or even introduce some of them as system wide option? Windows 10 release could include some of them.

 

Well MS's model is to keep everything enabled by default to ensure compatibility, not only with things now but with the future in mind as well. Like when .NET FW was first implemented there wasn't even anything that used it yet. And I almost feel like they make things dependent upon it just so it looks like it's not completely useless... but it's really not necessary to make the apps dependent on it at all, and only opens up more attack surface and creates bloat.

So I can't see them building the mitigations into the software. When it broke things the average Joe wouldn't know how to adjust the mitigations.

 

They don't have to enforce it by default. They can do the same as they did with ASLR in Vista. I don't see much problem for their own software (Office...). They surely can make it compatible with those mitigations.

 

That would raise the bar for attackers, but at the same time ensure that more effort is made by attackers to clear the higher bar.

 

And we get another cat-and-mouse game...

 

I can confirm that, EAF+ w/out any added module definitely makes sense.
However I'm not sure when I disable EAF and only enable EAF+, in this case maybe EAF+ alone w/out added module is meaningless? It seems whether EAF is enabled affects compatibility, so I assume EAF+ alone doesn't cover all EAF features, but not sure.

BTW, in post #789 I forgot to mention it was for ASR.
AcroRd32.exe ASR rule: ExtendScript.dll;rt3d.dll;ScCore.dll;A3DUtils.dll;NPSWF32.dll;Acrofx32.dll;authplay.dll
In ASR you have to specify modules, and if you register a module in ASR, you don't need to register it to EAF+ as ASR completely block load of the module.
But you may be bothered that every time ASR block loading, you'll get popup (you can disable it if you disable all notification though...).

 

Disarming and Bypassing EMET 5.1

 

Researchers Adapt Old Techniques to Bypass Microsoft EMET 5.1 Protections

 

That's why protecting against only "stage 1" techniques is not good enough. These researchers would not have been be able to run malware on a system protected by HMPA/MBAE because they block it in stage 2. However, it's still interesting that they were able to bypass this stuff.

 

Noticed an interesting approach in the "getting a bit paranoid" section: https://www.winhelp.us/microsoft-emet.html

Does anyone know which additions prevent secondary logons from working correctly according to them?

 

Can't help you there, but a good start would be to at least see if everything is working ok with the Flash plugin dll added to EAF+. Did you test this on both plugin-container and FlashPlayerPlugin?

Even if there are no known exploits yet of this kind, I think that if there's a way to improve EMET without causing problems or performance issues, then why not? Like some users have already stated here

 

From one of my previous posts: In the announcement of 5.0 TP there's a screenshot from where with only EAF+ enabled for IE, a Flash exploit was blocked.

But on the other hand when I have both EAF and EAF+ enabled for Firefox, it starts very slow. If I remove the xul.dll module from EAF+ it starts normally. But if I keep that and only disable EAF then it's fast again. So I'm not sure how EAF and EAF+ interacts. I hope someone can explain.

Edit: oops "then it's slow again" was wrong, changed to "then it's fast again"

 

While EAF+ is extensive version of EAF, I also observed same Firefox issue and it is addressed by disabling EAF so I assumed EAF+ don't include basic EAF function and it makes sense only when added modules are defined, but it's not based on facts so can well be wrong.
Because there seems to be no official documentation except they say EAF+ can be used either along with EAF or EAF+ alone, we have to test it to see if EAF+ w/out added module have EAF functionality.
I found HMPA test tool so maybe test it but also hope others confirm this.

 

Just upgraded to 5.1 yesterday, still a smooth sail. I'm lovin' it!

I'm guessing LSASS but don't rely on me for that.

 

I added all of them with most problematic mitigations disabled.
But some of them, namely csrss, smss, wininit, winlogon, are not protected by EMET and I can 'run as admin' w/out problem.

 

Just added everything listed, and experiencing no problems so far.

 

I can confirm EMET 5.1 doesn't crash my applications like 5.0 did. Now Caller, Stackpivot, EAF are enabled with no issues. So far. ^^

 

hey guys... should I add sandboxie and tinywall on EMET's protection list??

 

Upgraded a couple of machines from 5.0 to 5.1
Observations so far:
-I also have the Firefox EAF+ xul.dll startup slowdown
-VLC player now works with SimExecFlow enabled
-Tor Browser Bundle:
Tor.exe now works with Caller enabled
Firefox.exe now crashes with SimExecFlow enabled(I don't have this problem on the normal Firefox) and also has the xul.dll problem.

I have installed it by installing on top and chose Keep existing configuration + add Cert Trust rules, but on 2 machines all the Application rules were suddenly gone.
I exported existing rules which also included some executables which no longer existed. When importing these rules it adds them alphabetically and then stops with an error if an executable does not exist, every rule after that problematic rule is then not imported so you have to re-import it until all non-existing executable rules are gone.

It is generally not advisable to add security software to EMET, though the manual only mentions this with the EAF migitation, so you could try them without EAF.

 

Nope. Stick to apps that process/render data, especially those that are internet-facing.

While security software itself presents as possible attack surface, they are also the least likely to cooperate if tampered with. Therefore, I would caution against adding it onto EMET's list.

If there is any part of the security software code that needs to be optimized against memory corruption vuln (e.g. not employing ASLR), report it to the vendor and let them fix it.