EMET - A new Windows security mitigation toolkit

On my Vista Home Premium notebook i see a blue Questionmark ....not sure what it means...any help with the setup will be appreciated. Thank you.

 

Just a note to say I'm running EMET on my Windows 7 64 bit system. I'm reading the guide and MRK's site stuff as I go along.

I want to research a few things that may emerge as the reading proceeds:

1) It looks like I (user) id the applications I want protected for EMET so that implies it is dependant on user skill and knowlege. Hmmm.??

2) I'm wondering if I can/should add EMET itself to the applications list as an exploit MAY wish to attack EMET itself?

3) If a user (me) foolishly downloaded from or visted badsite.com with no AV no FW no router and got hit with a driveby parasite, how would EMET help me out? I have failed to put the .exe of the parasite in the EMET application list? Maybe as I learn more I will be able to answer this question.

 

@Escalader

My answers to that would be:

1) You don't need much user skill or knowledge to use it. All that is required is just a bit of searching and reading a bit of info here and there.

2) Interesting question. I don't know for sure but why not ask yourself this: Would you add Defensewall/Sandboxie/SpyShelter main executable(s) under their own protection scheme respectively? I doubt anyone would want to do that...perhaps the same logic can be applied to EMET?

3) I'm not entirely sure but I don't think EMET specifically protect against drive-by downloads. That's not what it's meant for imo. That job should rest better on the hands of HIPS, default-deny tools like AE/SRP/AppLocker, etc.

To see what EMET is meant for, please see here. There is also a PDF file included in the download that illustrates the concept behind it if I remembered correctly. It is mostly jargon and terms that we folks hardly see in our daily lives and therefore would fail to fully comprehend.

Nevertheless, the way I understand it is that EMET aims to reduce the chances/risks of a successful exploit from a vulnerability of an app (usually those that are known or has high potential of being targeted) under it's protection based on preventing already-known exploit techniques like Heap Spray, Null Page Allocation, etc. Instead of waiting for patches to be released when a vulnerability is found in such apps, you're taking a pro-active action and then hoping that the exploit would 'fail' under EMET. EMET by itself doesn't 'cure' or 'patch' the vulnerability or claim to lock-down all vulnerabilities. That is why it's specifically named with the word "mitigation" in it.

 

Interesting, indeed... I wonder if adding EMET under its own protection, if would provoke more harm to the protection it provides to the other apps, than good

 

The only problem I've had with this is adding Dropbox in configure apps. Dropbox wouldn't start if it was protected by EMET.

 

Hello again:

Here is MY status. NOTE: these are NOT recommendations just posted for information for the thread.

1) I've added EMET to the list of protected appln. So far no obvious issues.

2) In Mrk's site he advises:

Now I have many layers of "traditional" security and have added EMET to the layers in spite of the advice.

EMET is a bit clearer to me now and it seems to me to be dependant on users tagging existing applications and services to be EMET protected.

So given this assumption holds, EMET will NOT protect against a drive by parasite and I as a user will still be wise to have a top rated AV product in place to protect against these "new" exe's that cannot be placed in the EMET list.

If I'm wrong on this matter someone needs to advise and show why it is wrong.

Of course if I only visit my On line https banking site then none of this is needed BUT I'm on Wilders site right now and it is not a https site is it?

Comments? Alternate ideas?

 

I'm pretty sure I expressed all my thoughts on your specific question... regarding the "traditional" security protection, as you put it. Just read this thread behind.

But, I'd say you're not one of those folks, now are you? So, I won't be arguing with you the need for antiviruses, even considering they're no longer the "traditional" security once existed... they have evolved. I'm pretty sure you're more than capable of deciding for yourself the need of such tool; what I'd like to ask, and you do not have to answer (maybe more like a rhetorical question for yourself), is whether or not, considering all that has been said, proven, etc about the likes of Sandboxie, if such application would be a useful security layer?

As I mentioned, I don't really need EMET to protect my web browser. Nothing gets downloaded through it; period. I have no concerns with web browser security vulnerabilities, exploits... nothing.

But, what would you think of using web browser under EMET, and then under the protection of something like Sandboxie?

Considering Chromium:

1. You'd have its own sandbox protecting you;
2. Under EMET's protection;
3. Under Sandboxie protection.

I could think the same for Adobe Reader X, which now has a sandbox as well.

Any exploit would have a really hard time being successful, wouldn't you say?

I'm from the opinion that EMET is one more layer (I'm general speaking, and not individualizing) to add, and not the only one.

 

-Edit-

I missed this bit...

OK. But, what if you'd be facing an attack that EMET is meant to prevent/mitigate? Would EMET being under its own protection cripple such prevention/mitigation? That's my only doubt.

 

Adding EMET is pointless, since you will only protect the GUI of the program. The actual emet.dll added to the process is already protected.

@m00nbl00d, I agree with you that EMET just adds a layer off protection and must be used with other security tools. Making a computer exploit proof (which will never be achieved) will not prevent a average computer user to manually install malware thinking it's a free screensaver.

 

I'm agreeing with the last few posts that EMET adds a useful layer. I'm not agreeing we can abandon "traditional" AV's etc. The word "traditional" came from MRK's great site I can't claim I coined it.

Martijn2, how do we verify/know that emet.dll is protected? When I look at my list of "exe's" it ani'nt there?

These are just questions guys!

 

And, that's how it got discovered the world wasn't a square.

 

I think I read that SB blocks EMET's full function.
Not sure if that was accurate but is food for thought.

 

EMET can protect against drive-by downloads. See the browser tests at http://www.rationallyparanoid.com/articles/emet-testing.html.

Emet.dll is loaded inside each executable that EMET is protecting. You can use Process Explorer for verification.

 

Actually, you do bring to discussion a great matter. I did mention having a web browser protected by EMET, under Sandboxie, so I should have mentioned something else, as well.

Allow me to thank, before anything, to bring this up to discussion.

First, a little note of my own: I use Chromium as my web browser, and when I tried EMET, before installing it to relatives, I added Chromium under its protection, as well as Sandboxie. It did took a few seconds for the EMET check mark protection to appear in EMET's UI.

Now that you mentioned it, it seems that such was not happening, for what I could see; at least, not with the version of Chromium I got.

But, it's possible to have EMET under Sandboxie, by doing the following that is mentioned at Sandboxie's forum:

-http://www.sandboxie.com/phpbb/viewtopic.php?t=9631&sid=f1e9eb30c4f90172939aefec7931d0a2


Kind regards

 

Hello MrBrian!

TY for responding, I now see that since I use IE or FF to get to badsite.com the application being protected is the browser. How I missed this concept is due to old age!

I read the reference on the site and here for the thread is a quote on EMET limitations.

 

The site recommends that any service or application that listens on a port (faces WWW) should be added.

I added (ALL WINDOWS 7 64 BIT)

WININIT.EXE ID 524
SERVICES.EXE ID 628
LSASS.EXE ID 636
SVCHOST.EXE ID'S 820,924,984
WATADMINSVC.EXE ID 2684

When I rebooted at EMET's request system went down and came up in safe mode.

I'm exploring which one of these 7 exe's did this.

If anybody knows please inform the thread.

TY


Since then, the problem has gone away without me doing zip!

 

It's not how it's supposed to work.
You are not supposed to sandbox emet or windows binaries.
Just put your browser, p2p, pdf software and media player and that's it.
Mrk

 

I think it's also interesting to note that Chromium devs have actually stated that EMET doesn't provide any additional protection for Chromium based browsers.

http://blog.chromium.org/2010/11/compatibility-issues-with-emet.html

 

Yeah, I read that article some time ago. I just gave an example.

Still, for example, Chromium based browsers sandbox is flawed. There's a bad implementation of the low integrity level, which under a few conditions makes chrome.exe running with a medium integrity level.

Search the forum * for it... There are, at least, three different threads where such has been mentioned by Sully, Kees1958 and me, and corroborated by one other user I do not recall the nickname.

(I'll try to recover the links...)

Google's developers say they cannot reproduce it, yet we can. So, until something is figured out by Google's developers, many users could be in more risk than they would have thought, and simply because the implementation of Chromium based browsers sandbox (low integrity level) is poorly implemented.

That's the reason why I'm running Chromium with an explicit low integrity level. There's no risk for chrome.exe's IL to go to medium under those circumstances.

-edit-

* Wilders Security Forums, that is.

-edit-

Most recent thread: https://www.wilderssecurity.com/showthread.php?t=288332

https://www.wilderssecurity.com/showpost.php?p=1757933&postcount=247

 

Your advice here conflicts with

http://www.rationallyparanoid.com/ar...t-testing.html.

If you have time could you explain the reasons for these differences? My inclination is to follow your advice as it is easier.

Thing is selecting exe's to EMET depends on knowledge most don't have.

I have for example Genealogy SW that has a bad rap on security so I think that should go in like media players.

 

I don't see how it conflicts. See what they wrote about svchost.exe - they had to reboot the system to get it working again. Other than that, the rest are all third-party stuff.

You are not supposed to cripple os elements because then you get unexpected behavior. It's like saying not allowing the os kernel its full privileges. What you do is prevent other processes from gaining access to restricted parts of memory and running arbitrary code.

So if you prevent a browser from doing it, any of its children won't be able to do the same. And so forth. EMET the web-facing apps, like browser, im, mail, p2p, pdf, media, etc, and you're good.

Happy New Year!

Time to go and do a bit of modest partying ...

Cheers,
Mrk

 

Thks Mrk:

I removed svchost based on your post!

See you next years!

 

Escalader, you don't have to throw all those services into EMET. You will almost certainly cripple something sooner than later. Just follow Mrk's advice to add those apps he lists to it. It's better to take it slow, adding one or two at a time, then wait to see if something breaks before adding anything else.

 

I agree, besides, for them to be exploited the user needs to execute something, or perhaps an exploit via a third-party program, but you can protect the third party program with Emet. You can protect the windows services with DEP, Sehop and ASLR through the system-wide settings, check the manual on how to unlock the setting Always On for ASLR.

 

How do you make SEHOP and ASLR Always On?