SEMET (Somewhat Enhanced Mitigation Experience Toolkit)

Hehehe...okay first off, anyone that knows me knows that I do love EMET quite a bit. It's clean, yet very powerful, is very proactively being developed, and with just a few clicks you can add invaluable layers of protection to your system that prevent other layers of your security from getting exploited as well as protect you from your own software being used against you.

As for the whole experience of EMET...it's mostly grand. Until you uncheck DEP for a program...and DEP still terminates it. So we begin our tale. I asked this question awhile back and HungryMan informed me "EMET isn't meant to exclude something...it either forces it or does not force it." Erm...okay. I sort of get that. But here's my issue with that. It's confusing! And it's not explained well! And quite frankly, it should be better!

Admittedly, someone will find a pro-reason why it cannot or is not like the way I wish it to be, but still...don't I at least make a good point?

Here's how EMET currently works (assuming you have a basic knowledge of system mitigation opt in vs opt out already):

System Mitigations - always off, always on, self-explanatory. If you choose those settings of course there can be no exceptions. That's the point.

Opt in - I believe you can opt apps in through EMET using Configure Apps.
Opt Out - Ah...but what's this...DEP crashes a program, so I add it to EMET Configure Apps list and uncheck DEP...it still crashes. I still have to add this to my DEP exception list in the Control Panel / System of Windows? Why?!

Not only is that confusing, unintuitive, inconvenient, and frankly annoying, but it is risky. If EMET cannot opt out programs from your system mitigations, what happens if SEHOP crashes a program? Then there's no way to opt it out because there is no other way of turning off SEHOP other than EMET...unless you go into the registry or use command lines.

I also ran into an even more confusing situation where I have DEP system wide set to Opt Out so it should be applied for every app by default, right, unless I opt them out specifically? That's the whole fundamental idea behind Opt Out. Oddly enough...EMET was crashing a program due to DEP that normally was compatible with my system wide DEP. I unchecked DEP in Configure Apps, and the program worked. This got me excited that maybe they finally implemented it the way I always wanted it to be in the latest EMET 3.0, but nope, that was just an oddity. I tried removing some entries from my Control Panel / System DEP exception list and unchecked them instead in EMET and they again did not work.

Are you confused reading all that? My point exactly. It's confusing!

Why can't we just have ONE list of mitigations? I say we shall, or it is not truly a fully enhanced mitigation experience! Especially since I've learned all this in practice and none of it is documented nor do they warn you about this in mouse-overs or any tool-tips or such!

How I wish EMET worked:

System Mitigations - Always On/Always Off no exceptions. That's obvious.

Opt In - Programs are not forced unless you check the corresponding system mitigations in Configure Apps.

Opt Out - Programs are forced by default unless you uncheck the corresponding system mitigation in Configure Apps.

**When EMET is installed, by default, controlled with a registry value, EMET will gray out your DEP controls in Control Panel and add a note at the bottom of the dialogue saying "Please configure these using Enhanced Mitigation Experience Toolkit GUI".

What is the point of having DEP and SEHOP present as tickboxes in the Configure Apps if they just "force or do not force." That's useless. It is useless to have to set it there and then make sure you also set it some place else. Especially since SEHOP and ASLR don't have a "someplace else."

Note that I do understand that ASLR is different since by default Opt Out is not an option. You can only opt programs in.

I also understand for the other mitigations that are not system wide ones, and are just application only, obviously, those checkboxes will either force or not force. That makes sense. But for the system wide ones, why can't it be "force or not force" if you set it to Opt In, but actually work correctly as an Opt Out if you set your system mitigations in such a way?

So in other words, I'm trying not to make this more confusing than it is...

For system migitations you set to Opt In, having the Configure Apps be a check the box for "force", and uncheck the box for "do not force" makes sense.

For system mitigations you ste to Opt Out, however, checking the boxes in Configure Apps should be "keep it forced" and unchecking it should be "opt it out".

I don't know...it just remains weird and a bit frustrating to me to have to maintain two lists.

 

Here's how the system works:

If you set system wide settings for DEP to Opt In (default) you can use Application Settings to then force DEP on a per process basis.

If you set system wide settinsg for DEP to Opt Out (programs have to explicitly build without it) you can override programs' choices using application settings.

If you want to opt a program out you have to use the systems interface.

Not forcing an application does not mean forcing an application to not use it. It instead leaves it up to the system settings as well as the programs settings. It just doesn't mess with it at all.

It's really simple in my opinion.

Now if this is the case that's another story. It didn't used to be but maybe an update has done this? If so simply report this to Microsoft.

Maybe things have changed but before you could still use the interface in the system settings.

 

I like EMET too, I use it and do like it. But I see a problem of making the application too technical for standard users. Which is a big problem, once you start adding layers the technology starts to become bad to use without super skills and knowledge.

I think it's going well and being developed actively. I get what your saying you want more but at the same time it's pretty good as is. I think after Windows 8 comes online we will see some new features.

 

It's not the case...I was talking about I WISHED EMET would be, hyopthetically.

But answer me this, if you're in favor of how EMET is now, which I am not...

If SEHOP is opt out system wide and it crashes a program I need, how do I add an exception GUIically?

I can't.

In other words HungryMan, I want to only have to manage ONE list of apps for opt ins and outs for all my mitigations. It's annoying and confusing to have to add some to one list then open the control panel and add to another list.

EMET app control SHOULD be able to opt out just as it opts in.

 

But you never could. Whether EMET is installed or not SEHOP is set to Opt Out or Always On. EMET being installed doesn't change this.

It would be nice if you could opt out from the same panel, I agree. But more for simple convenience.

 

About SEHOP you're right. I forgot about that. It's been that long since I changed my sys config options. /embarassed

I guess what I really want EMET to do is grey out your DEP control in the normal Control Panel place and allow you to have just one area to manage all mitigations...

But the way it is currently, DEP is left in a awkward place imo. You can force or not force it in one list, but you need another list to opt it out.

Or rename the product to Enhanced but Slight Inconvience with DEP Setting Mitigation Experience Toolkit (ESIDSMET)

 

I have a way to further complicate matters ! add a another program to the mix. Heaplocker from Didier Stevens

Emet tech preview is at 3.5. Still I'm glad that there is such a tool like EMET or Heaplocker, but hopefully future versions of EMET will be better and understandable beyond any doubt. I mean, not to first include all apps as Opt-In and then create second list to Opt-Out individual parts or programs.

 

I wouldn't want to run them both concurrently as they'd potentially conflict. Heaplocker will protects common memory addresses with an anti-heapspray mechanism by reserving those spaces so if a malicious heapspray occurs, it can not write to those spaces. It has a switch that can inject harmless shellcode into those spaces it reserves which, if executed, will freeze the threat(s) and generate a message to the user. This is what its author, Didier Stevens, claims. I don't know if EMET 3.5 protects this way or not.

 

Indeed, I do see your concern and that's what I meant with complicating matters even further. I see your point not using both tools at the same time. But I also have to admit that my knowledge about Heaplocker is limited. I suppose if you use heaplocker on one executable/dll, then the same exe/dll can't be protected with EMET at the same time. But I'm highly speculating here, don't have enough knowledge about it. But what you've mentioned makes sense. Best be careful what you protect with EMET and what to protect with Heaplocker, if it does what is says it would. seems like heaplocker is still in very early development stage.

I am also not sure about the 3.5 version of Emet, I like to keep using official released versions or stable versions.
At least 3.0 of EMET does have a notifier (in systray), it notifies when something is blocked. previous versions of EMET did not have a notifier like Didier Stevens claims. However I'm not sure if D. Stevens is aware of the notifier in emet 3.0

 

My knowledge is very limited on these mechanisms as well. I only know about the Heaplocker heapspray protection because of a youtube video of the author's description. He also very nicely describes how EMET uses a shim dll to protect legacy apps or those where the developer didn't include ASLR protection He seems not to be aware of the pop up notification feature in EMET.

I've included a Process explorer screenshot where this shim is used to protect a realtek systm tray utility. This reminds me, I can probably disable this process in autoruns

 

Oh...another I have been confused about...

You know the task list chart on EMET GUI? It shows a mark if a program is running with EMET. It also shows a mark if the program is running with DEP. But why is DEP the only one it shows a mark for? Why is DEP the star, one mitigation you can check the status of?

 

I've found another free app that can scan executables (exe, dll, ocx, sys, mui, etcetera) before they run to check if dep, aslr is enabled. many more things can be checked as well.

http://www.winitor.com/index.html

the program is called PeStudio and you see a screenshot of it when you are at the mainpage. I think you should check it out if you're interested.

 

DEP(Always On) has created problems for autopatcher(Setup.exe has stopped working) and some drivers of my Toshiba C660 laptop(Audio drivers and Intel Management Engine Interface simply refuse to run).

So I changed DEP system wide settings to Opt-Out and added Autopatcher to the Control Panel DEP exception list. The drivers ran just fine without adding them to the exceptions list.

My question is since STV stated that unticking DEP in the Configure Apps list does not help, assuming a scenario where I configure the system wide settings to the following:

DEP Always On
SEHOP Opt-Out
ASLR Opt-In

and do not configure any applications in the Configure Apps list I should
be able to see emet.dll (emet shim) in process explorer for any application
that I open by double clicking but I dont see any. The fact that DEP is being
implemented system wide is proven when Autopatcher and those drivers fail
to load without configuring them in the Configure Apps section. So how
come I dont see emet.dll when I only configure system wide DEP setting and not configure apps section??

In other words how can it be proven in Process Explorer that DEP(or SEHOP/ASLR) is being applied system wide when it is configured through Configure System and not Configure Apps??

 

EMET.dll isn't used for system wide settings. Those are handled at boot. The system ignores the bit flipped for DEP/ASLR.

 

So do you mean to say that DEP/ASLR which is configured for system wide settings is enabled at the kernel level which means individual programs still need to be protected by DEP/ASLR through Configure Apps??

 

No, the kernel ASLR and DEP are entirely separate. The policy is handled at boot though.

The kernel, or whatever policy manager, will check if a program uses ASLR or not. Or, if you set it to "Always On" it'll not bother checking, and simply use ASLR.

 

Hungry, on vanilla Win7, DEP is default always enabled for windows services and can be set for 'system wide (with exclusion list)'.
When using the OS functionality for DEP systemwide, can EMET actually disable DEP by selecting 'application opt-in'? Can EMET overrule such OS configuration?

When using OS-DEP system wide, this negates the need for EMET Configure Apps.
It's even faster to use the OS method and use DEP 'System wide' with an exclusion list for 'Autopatcher' and drivers than building an EMET opt-in list. This still leaves ASLR (and all other) settings oc.

 

Those services are opting in, explicitly.

I don't think that's an OS configuration, I think all MS binaries are just compiled with strict DEP.

 

I mean when you use; System; Advanced System Settings; Advanced; Performance; Settings; Turn on DEP for all programs and services link, EMET 'DEP Application Opt-in', can't disable such OS setting for all programs, right?

 

You could just change DEP under EMET's Configure System to "Always On". This I think should eliminate concern over EMET disabling it for any program.

 

Turn on DEP for essential Windows programs and services only
= DEP Application Opt In

Turn on DEP for all programs and services except those I select
(and if you have a list of exclusions there)
= DEP Application Opt Out

Turn on DEP for all programs and services except those I select
(and no list of exclusions there)
= DEP Always On

 

If you set it to Opt-In it will still run those programs with DEP and it will also let other programs opt into using DEP.

I don't think it would disable it on them unless you turned DEP off.