EMET - A new Windows security mitigation toolkit

A very broad statement which in itself is true but simply isn't true in the case of EMET as I've already explained to you.

There's nothing to add, only the GUI. A pointless endeavor.

I generally see you arguing about something you're wrong about every other week. Malware not exploiting 0 days was a funny one, but sometimes it's better to just let people be, rather than beat your head on a brick wall. But that's veering OT on this topic.

 

You misunderstood what I Was saying but that's off topic.

You haven't explained how EMET is somehow not an attack vector.

Edit: Again, to break it down.

EMET uses .dll injection
EMET lives in user space

 

So what isn't an attack vector then? Every security measure opens something up, drills deep into the OS, hooks itself.

 

When something lives in user land it's much easier to manipulate and attack.

If EMET were built into the kernel space there would be far more security involved in it. No idea why Microsoft hasn't done this already.

 

Already stated:

It is barely doing anything other than calling existing O.S. API to run the program in a different fashion. What you're trying to describe is something like running a browser then injecting a DLL to allow another program to read transmitted data. That would increase the attack surface as you're not only adding additional code, you're creating a passageway into another program which could have exploits. Again, EMET does not run this way. It isn't in essence, a "program", if it helps you imagine it better.

Nonsense, there is no need to run anything other than the bare minimum in kernel space. You should go read about the WebGL issues due to it running code in kernel space to see why you don't just run anything you feel like there.

 

WebGL is insecure for whole other reasons that don't apply to EMET because WebGL is internet facing.

EMET should not be in userspace. It's that simple.

 

Ok, you obviously know better than Microsoft engineers, again I'll leave the argument here.

 

That's not even an argument.

But ok, this was boring and not very educational at all.

 

Microsoft EMET is a light-weight and easy-to use software, and I personally consider this a excellent security (“against a frequently exploited class of software vulnerabilities”) addition to my current setup. And apparently I’m not the only one to see EMET value, highly reputable people with first-hand knowledge and experience with exploiting all had positive feedback after various tests each one had done.

To protect against exploitation of commonly targeted applications, and Internet-facing services is a real winner especially for those who loves surfing the world wide web and on social and p2p networks, and for those who hosting different types of servers.

My family with older slower computers aren’t minding this extra light-weight and easy-to use layer of protection, they know when the browser process terminates, it’s likely Microsoft EMET just helped prevented a successful attack (but I check the dumps anyways). Priceless and awesome freeware security addition to the family systems, that is protection for more than theoretically threats. Lot less worries about the family running into malicious areas on the web and being a victim of a exploit attack because their browser or their browser plugins they use are always targeted.


To ponder over EMET self protection against local infections is irrelevant, that is why we don’t solely rely on a single layer of protection. And so far, EMET been available to the public since Oct 2009 (I believe), we have any mentioning of EMET dangers?

 

Well, I'm coming late to the game. I just installed EMET 2.1 and have just started doing some reading. I already have DEP turned ON for all applications and set DEP in EMET "opt out". SEHOP and ASLR are set "Opt In". I've added my browsers and Windows Live Mail to the Opt In list, all features enabled, and they work fine. However when I added Outlook 2003 it crashed whenever I accessed the calendar function, so I removed it. I see this as the main problem with EMET, ie that it's a matter of trial and error to figure out which apps can Opt In, and which features for each app can be enabled. This is too labor intensive for people in the know, let alone newbies. What would really increase the value of EMET is a "front end" that includes a database of tested apps and that would automatically Opt In and configure those apps.

Regarding the question of whether or not EMET increases the attack surface, you could say that all security applications increase the attack surface because they themselves are potentially exploitable, but that seems like a meaningless argument to me. The question to ask about EMET (and all other security applications) is does it significantly increase security and are there any currently known vulnerabilities that would discourage its use? Vulnerabilities are constantly being discovered so the question can only be answered in the present.

Just my .02 And if anyone knows about an EMET front end app I'd love to hear about it.

 

You could simply remove Outlook 2003.

I have a few applications forced with EMET and the only problem I've had is with EAF and silverlight.

http://rationallyparanoid.com/articles/emet-testing.html
This is an (old) article showing EMET protecting applications against known exploits.

I think EMET is best used with internet facing applications but specifically:
Java
Adobe Reader
Flash

since those three are very often targeted.

My current EMET settings:
DEP Always On
SEHOP Opt Out
ASLR Opt In

 

EMET Application Compatibility Issues

 

Thanks for the details. I decided to add Outlook 2003 back in with EAF disabled and so far it's working OK. Since you have SEHOP set to Opt Out are you finding that pretty much everything supports it or have you needed to exclude some apps?

 

I have not had an issue with SEHOP Opt Out or even DEP Always On. I only wish I could try setting ASLR to Opt Out.

 

Guys, I've managed to screw up bigtime; specifically SBIE, by adding several Windows\System32 processes (several at a time) to EMET 2.1 (Vista SP2 x86)
Afer a reboot, SBIE started to nag about a missing version.dll file and refused to function.
I guess I added one process/setting too much, probably EAF or BUR.
(No, I didn't log which processes/settings I added. Stupid, I know... )

My previous safe EMET app setting included all SBIE processes and SBIE ran flawless.
The problem now is, when I uninstall EMET, reboot and reinstall EMET, it will automatically import the unsafe EMET app settings but for the life of me, I can't find that config file.

I've searched on the rationallyparanoid EMET settings blog, checked the MS EMET support page at MS Security TechCenter and turned my HDD inside out but no luck.

Even when uninstalling SBIE and EMET->reboot->installing EMET->removing all apps setting->reboot->applying save EMET settings and only then installing SBIE, it will be borked again as if the unsafe EMET configuration still applies.
When I have SBIE without EMET installed, SBIE works fine.
Funny thing is though, with EMET uninstalled->reboot->SBIE install, I got the SBIE security software compatibility popup, indicating that I had an AV, a firewall and...EMET installed.
I'm stumped...
Anyone know where I can find this friday evening config file nemesis or how I can solve this puzzle (without slapping on a fresh image)?

 

You really ought to add just your internet facing programs and configure the exes that are already listed. Sandboxie doesn't need protection, IMHO. Adding everything to EMET is just going to cause issues like you're facing, Baserk.

Edit: EMET still "haunts" my system after I've uninstalled it as well. It seems to just be a matter of a poor uninstall utility. I'd meander through the program files and registry to find leftovers.

 

Initially I only had a safe 'internet-facing apps' setting and then I started (recklessly...sigh) to add EMET settings to those (mainly) System32 processes listed in the EMET list.
SBIE perhaps doesn't need EMET 'on top' but it did work just fine with SBIE processes added to my 'safe setting'.

Will go through it once more tomorrow and see if I can expel this haunting behaviour.
I'll also try the Dogbert approach;

~ Removed Copyrighted Image as per TOS ~

 

Remove the protections and delete the EMET.dll. That's my best bet.

 

Yes, indeed. We shouldn't add system processes to EMET like that. Even explorer.exe. It may not breaks things, at the surface, but we don't know about what we can't see.

I wouldn't add explorer.exe to EMET just because of my compression tool doesn't support ASLR, for example.

We can't predit problems. Once thet happen...

 

So why is Microsoft moving drivers from the kernel space to the user space starting with Vista -- as a security effort? Do you know who praised this move? The creator of MINIX (one of, if not THE, most secure OS, also the inspirer of Linux): Andrew S. Tanenbaum

Kernel Patch Protection (KPP), informally known as PatchGuard, is another effort from Microsoft towards making developers avoid developing apps that patch the Windows kernel.

This is secure: http://en.wikipedia.org/wiki/Microkernel#Security

 

lol you've misunderstood entirely. Throwing everything into the kernel is idiotic and not something I am suggesting or something I would ever suggest.

Security should be in the kernel. That doesn't mean I want, say, Firefox built into the kernel or my word editor built in. Or... in this case, Internet Explorer/Graphics.

And PatchGuard is irrelevant and that isn't what it's for.

EDIT: And if you'd like I can elaborate more on why EMET should be built in and why it's still a good idea to shrink the kernel where possible.

 

I would agree that the security features unmasked by EMET should be built-in, but since they weren't it seems better to have EMET as a retrofit than to have to wait for the next iteration of the operating system, don't you think?

 

Explain this.

 

Absolutely.

EMET should not be taken away just so that the next OS can have it built in. They should have the next OS have EMET built in and they should have EMET as a retroactive tool for older OS's.

ok

This is what you said.

PatchGuard is not for discouraging developers from touching the kernel. It's simply there to control who can.

If malware can touch the kernel it's an issue. If a certified application can it's less of an issue.

MINIX takes another approach, which is to limit what kernel-calls each application can make.

Both are effective.

 

If memory serves KPP was originally meant to keep everyone out, but the third party AV developers complained and MS developed APIs to give them access - is that correct? It's hard to argue this either way. Seems like locking down the kernel would be the better choice, but since nothing is absolute and the malware writers will find a way to break in maybe it's better for the security vendors to have legitimate access? It's worth noting that KPP is effective enough to force the TDSS4 rootkit writers to resort to a boot sector exploit to get around it.