EMET (Enhanced Mitigation Experience Toolkit)

Had a couple of points, and questions to bring up, and wanted to start a fresh thread on the topic/tool. As the others have some OT stuff, even a rant here or there (one I'm not too proud to admit was my doing). And people don't need to dig through that for info. on EMET.

I noticed via a link in one of the other threads that a new beta of v3.5 is planned for release any day now. Supposedly with new "features". Heck... I'd rather they just ironed out the features they already have in place now before playing around with new ones. I mean supposedly even the DEP is broken in 3.5. Geez... that ought ta be addressed before moving on to new toys.

Is the DEP in v3 and/or older okay?

I'd rather see a stable version of whatever they have a firm grip on right now than for this tool to remain in a perpetual beta phase because they keep adding more stuff before ironing out what's already there.

This thread is also for any other open discussion of any type regarding EMET.

 

Yeah, forced DEP is working fine in 3.0 and 2.1 when I checked. Of course this doesn't affect people that, should probably at a minimum, have system DEP set to OptOut (except EMET won't make it Permanent for the process) or AlwaysOn (EMET's DEP is irrelevant).


Now it's April, and still waiting for that next 3.x beta. (I'd guess it's 3.6(?) or something, but not 3.5...)

 

New (beta) version finally supposed to be coming this week! According to https://twitter.com/jness/status/323944205149933568

Wonder if things will still be on track for a "final" summer release (https://twitter.com/jness/status/302128486804500481). Not that I really care...

 

@luciddream

If you want further details, DR_LaRRY_PEpPeR has posted the subject on EMET forum here.

Anyway, I think it's fairly reasonable to say that most who chose to use EMET 3.5TP for the extra ROP mitigations would have at least set DEP to OptOut; if not AlwaysOn. In short, while it's a lame bug, I would not consider it a deal-breaker.

@ DR_LaRRY_PEpPeR

Yeah. Read something along those lines from elsewhere. Still can't help but to wonder what the new (beta) version will bring onto the table. It'd be nice if they start to introduce "support" for Win8.

 

finally, not a fan of 'technical previews'.

 

OUT!!


http://blogs.technet.com/b/srd/archive/2013/04/18/introducing-emet-v4-beta.aspx


8 Pro X64:
it works as expected

 

And... it's out: http://blogs.technet.com/b/srd/archive/2013/04/18/introducing-emet-v4-beta.aspx

So it DID go to version 4 -- to be an official, non-beta release on May 14. Some different new features to check out... Uses .NET Framework 4 now (already have it, just sayin' for others).

"Wildcard support when adding applications," not sure if that means it just finds matching files, and then adds them non-wildcarded (like I think NEMET says it can do), or if the run-time matching is actually using wildcards, which is NOT possible using the EMET 2-3.5 AppCompat mechanism, IF they moved away from that (not that they did). But, I was waiting for this next release, to see if it changed anything major that might affect me creating the "Open EMET" interface, etc.

(Nevermind the above, just installed on other system to look, and the operation/config is as before. )

Unfortunately don't have time to check it out right now, but will as soon as I can!

 

Alright! An EMET that uses Net Framework 4.

Nice.

BTW, if you include an antikeylogger (like KeyScrambler or Zemana) in your applications list you'll get a ROP error on reboot (at least I did). To still list it but not receive this error then just uncheck SimExecFlow. This is on Win 8 Pro 64 bit.

Later...

 

Should I do a clean install or not? Currently have 3.5 TP. Thanks!

 

The newest version installs to C:\Program Files\EMET 4.0 (Beta). So, I believe it should be best to disable mitigations to for any process, then uninstall, reboot and install the new version. (This is what I did, just in case.)

Of course, you should first export emet mitigations.

 

So I can do export, disable mitigations (should I also restore to default DEP, SEHOP and ASLR? Currently have Always On, Opt Out, Always on respectively). then uninstall 3.5 TP, install beta then import? Thanks

 

Yes, you can export your current mitigations. It's saved to a *.xml file (make sure you save it in a location you remember afterwards ).

I didn't disable system wide migations. I kept those enabled.

But, before you import the application mitigations, remove the mitigations that version 4 enabled by default. (But before you remove v4 mitigations, don't forget to see if it's protecting some process(es) that you aren't already mitigating. If it is, leave it enabled of course, as there's some reason why they added it there. )

 

Two minor things I noticed in version 4 Beta
1. When a program protected by EMET is run in Sandboxie, it won't be showed as not EMET protected in the GUI (Can be easily fixed though as it happened before)
2. When running under a Standard User Account, with tray enabled, if you open EMET Gui, a message EMET Agent not running. I think it is caused by Emet Agent is running in the user Standard User while Emet GUI is running in the user Admin. If I am in an admin account, this does not happen.

 

Firefox shows up as EMET protected while running inside Sandboxie for me. But I do have SbieCtrl and SbieSvc listed as a EMET protected application.

Later...

 

I noticed 2. as well.

By the way, not sure if it was already present in previous versions, which is something that I totally missed, but with this version, when we open the GUI we can right-click a process and add it to EMET. A nice touch!

 

Hmm, I am using Sandboxie 4.0.5 . How about you? (This is my test machine )

 

Sandboxie 4.01.05 here as well.

Later...

 

I'm not seeing this -- still shows protected in EMET under Sandboxie... As far as I see, it's still using the same method for detection (\BaseNamedObjects\EMET_PID_nnn Event).

Now however, the notifier/Agent will not actually be notified if EMET is triggered inside Sandboxie. The EMET Template will need to be updated -- I'll post on Sandboxie forum later (need to verify which thing needs access) and back here I guess.

It's now using a "Mailslot" to send notifications to the notifier, not window messages, which means my test EMET Notifier would not work (the type of change I was wondering about before starting a new EMET alternative). I'll check in a bit if I can replicate the new notifier mechanism and receive the messages again. Hope I get it working, but again, I really have no idea what I'm doing!

Oh, that's good (no, it wasn't). That was another thing I was going to do (like NEMET I think).

 

Hmm, are you guys on Windows 7 x64 ? I guess there is an issue in my machine, I think I'll make a report on Sandboxie forums later if I'm still awake.

 

No, XP, but I don't know that it makes a difference (I'll check on 64-bit 7 later). You DO have SBIE's Software Compatibility enabled for EMET, right? (I assume you have for a while. )

 

Nice, EMET is indeed evolving as promised also ROP has deep (hard) hooks, detour protection and checks on 'banned' (sloppy, exploitable) functions (see pic). This should close the EMET ROP gap of 3.5 beta

 

I have it enabled. I even checked if the settings is there the emet_pid_*. Now that you mentioned it, I remember tzuk saying there are differences in how Sandboxie works (starting version 4) in XP and 7. I am looking forward to your Windows 7 x64 rig.

 

I know this is a bit off-topic, but I'd just like to mentioned that Chromium/Chrome users can use similar functionality using the flag --hsts-hosts.

I'm glad to see EMET brings it to IE.

 

Running the 4 beta on Windows 8 x64. Seems good so far.

-I see WinZip still does not work with the settings imported from the included .xml files. I am running version 17, and I see they added the 64 bit executable to the .xml file, so I would think they would have the right settings. I guess I'll have to tweak the settings until I find out which one breaks it.

--That was quick. Looks like disabling SEHOP allows it to run.

 

I have now posted about EMET 4 Compatibility settings on the Sandboxie forum. In short, until the SBIE Template is updated, you need to add:

OpenPipePath=\Device\Mailslot\EMET_Agent_*

Or from the GUI, add the bold part (after =) from Resource Access > File Access > Full Access

This is only for the notification to work if EMET actually gets triggered in a sandboxed program. Stuff will still show as protected with the current Sandboxie Template settings.

How are you launching your programs? With Run Sandboxed/Sandboxie Start Menu? Or forced or from something already running sandboxed? Anyway, after trying stuff (for myself and after your post), I realized the former methods aren't even letting EMET get loaded since SBIE 4.01.04 (see above forum thread). There does not seem to be any issue though with EMET showing sandboxed programs as protected IF EMET actually gets loaded and is protecting them. In other words, what the EMET GUI is showing should be correct in all cases, as long as you have Sandboxie's current EMET Compatibility Template enabled.