NEMET

HungryMan is right... NEMET will indeed still work if you uninstall .NET FW afterward. Makes sense since .NET FW is only needed for the EMET GUI, and NEMET works as an alternate one. But I just needed to install .NET FW first to install EMET, to get NEMET to store my app specific rules. Because those redeployment packs just would not take without .NET FW installed.

So between Hardware DEP (AlwaysOn), SEHOP & (pseudo)-ASLR provided by WehnTrust, and Comodo D+'s Buffer Overflow Protection, I'd say I'm about as covered in this area as an XP user can be... and without taking on the surface/bloat of .NET FW.

I'm happy.

But before you rush to mimic my setup, please read what I wrote about WehnTrust in the "other security, software" section". It is a fickle program that seems to have a mind of it's own. I tried this same approach out on a box that was virtually identical, and WehnTrusts randomization driver failed to install properly, then BSOD after a reboot. It is working for me, but I do not recommend it.

 

Quick question, and I didn't want to start a new thread over it. It's about EMET, not NEMET.

Do you have to keep the EMET Notifier in the try enabled for EMET's protection to continue to work? It's using like 27,000K of memory, so I get the feeling it's more than just a notifier and is what is making the actual program work. But I could of course be wrong. And if it's not needed for the protection to work, I'd certainly rather it not be there.

And if it indeed isn't needed for EMET's protection, what does it do? Just notify you when it blocks an exploit? If you disable it, would you not be notified then? Or worse... would it not block the exploit then?

Thanks. On a test machine I removed .NET FW to see if NEMET would still work, and it does. But on my main I still have .NET FW 2.0 SP2 & EMET 3.5. And I may just keep it like this. On this new/old box of mine it's not nearly the drag I remember it being before. Perhaps in part too due to the fact I only installed 2.0, where I used to install them all, up to 3.5. And also after the .NET FW Optimization service does it's "run once" thing after the first reboot you can safely disable the service from there on out and EMET works just fine. Also disabled that ASP.NET service & deleted the account. And not a peep from .NET FW from my D+ since disabling it. So really you can render all that "attack surface" I kept jabbering on about inert with a few measures, and enjoy the benefits of EMET without any cons.

I only wish WehnTrust didn't conflict with Comodo's D+ so I could get the ASLR & SEHOP too, but you can't win them all. D+'s protection against shellcode injection is accomplishing about the same thing.

 

AFAIK, No.

AFAIK, Yes.

No, but it will make an entry in the eventlog.

AFAIK, it will still block the exploit.

That's interesting because it wasn't working for me even with .NET still installed. That was in an XP VM, so I'm not sure if that makes a difference. I'm hedging my answers due to the differences we are seeing with NEMET. Also my EMET answers are based on my observations in Windows 7 x64. Hopefully, they're all correct; perhaps someone on XP can verify their accuracy.

 

Well when I say it "worked" that's in very relative terms. Meaning it would still open, state that things were protected by EMET, and that I could create app rules. But I'm not entirely convinced it was actually providing the protections. And as soon as I'd close the GUI, as I stated in our correspondence, all the protection (if it was ever there) would go kaput too. So unless you leave the thing minimized perpetually... And no matter what I do I can't get the thing to install any of the redeployment packs I make.

Really after further review I can't really recommend either NEMET or WehnTrust. The latter... maybe for your computer illiterate friends/family still on XP that can't grasp an outbound FW/HIPS, for some extra protection against exploits, namely buffer overflow.

But I'd rather just install .NET FW 2.0 SP2, fully patched, let it do it's run once optimization thing after the initial reboot. Then disable it and the ASPnet service (+ delete the user acct.). Maybe tighten .NET FW in HIPS too if you feel the need. Then install EMET. Now with a proper CPU & more RAM I notice no bloat as I did in the past. It really was much ado about nothing... the fuss I raised over it. I wish I'd just done this from the get-go now instead of trying to get too cute... but at least I learned a few things.

 

You don't need .NET Framework, NEMET, or even any of the EMET stuff in %ProgramFiles% for EMET to work. Although, if you uninstall EMET, it may remove the necessary stuff from Windows\AppPatch (the EMET DLL and the .sdb database in Custom). THAT is all that's needed for EMET to "run" (e.g. protect processes), along with the companion registry stuff at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\ (under Custom and InstalledSDB) and HKLM\SOFTWARE\Microsoft\EMET.

So it does need the Application Compatibility database stuff to function, and won't work in another way I wondered about to load the DLL into certain processes without installing EMET at all -- the DLL can be loaded but that doesn't do anything (other than creating the EMET_Settings env var...), the AppCompat API stuff isn't called/activated/etc. e.g. no Event \BaseNamedObjects\EMET_PID_nnn created (Process Explorer) which is how the EMET GUI checks if a process is running EMET.

Since I sort of said I was looking into creating some kind of EMET alternative (if an XP user doesn't want to install .NET FW (I don't like but it doesn't bother me since I have other stuff that needs it); or if I can add some enhancement(s) that user would like; and just to work on something ), I think I worked out all of the stuff to write the .sdb files (like the NEMET guy did, I'm not sure what he did, but I thought it was much more complicated than it appears (easy?)), simply by using EMET's SdbHelper.dll...

Of course NEMET won't give you the Notifier, nor allow you to set the new mitigations in EMET 3.5+. Another EMET release is coming in a few weeks -- can't wait to see what it adds/changes.

And the EMET Notifier seems pretty simple as well. Yeah, it's just an informational thing, and doesn't affect EMET's protections. If you close it or disable it from starting, programs would just crash in a "normal" way, with no indication that it was from EMET. And unlike what 0strodamus said, you will NOT get an Event Log entry about it, since the Notifier handles the logging. I'm running my dead-simple test replacement(attached): no Event entries. Of course I could (would?) add the logging ability if it's going to be a good replacement. Right now in the test screen shot, it's just showing a pop-up MessageBox (simple, although some may prefer it like that...?), but I assumed I'd use a system tray balloon tip to notify? And of course I'd like to have the ability to HIDE the Notifier icon unless there's a notification. Hopefully I can manage since I pretty much have no idea what I'm doing with GUI stuff!


Implementation: The "window" (hidden) has to be named EMET_notifier, since that's what the EMET DLL looks for, and the .exe is named that so Sandboxie's EMET Software Compatibility setting allows messages to be sent to it from sandboxed programs (so it's a seamless replacement). Other than that, just:

Code:

case WM_COPYDATA:
{
	char dwData[64];
	COPYDATASTRUCT *stuff = (COPYDATASTRUCT *) lParam;

	// No dwData...
	sprintf(dwData, "h4X0red EMET Notifier (dwData: 0x%x [%d])", stuff->dwData, stuff->dwData);

	MessageBoxA(NULL, stuff->lpData, "h4X0red EMET Notifier", MB_ICONINFORMATION | MB_OK);
}

I'm not sure what the special meaning of the nnn| number is at the beginning of the message (it's the same for each message of the same "type"). 2 messages are sent when a mitigation is triggered: the first with prog.exe to be displayed, and the second with \full\path\to\prog.exe which is what's supposed to be sent to the Event Log...

 

Yeah... I just figured that out myself too the other day. If I had known this from the start going in, it would've saved me a good bit of trouble. But hey, that's how you learn.

Didn't realize there was another release planned in a few weeks. I wonder if it's simply a final release for 3.5? Or if there will be more features/changes too. 3.5 seems plenty stable to me.

Right now I'm testing my apps to see exactly which mitigation techs I can deploy with them while retaining essential functionality. So the EMET Notifier is certainly a welcome component to me right now at least. Once I get everything the way I want it though it'll probably go.

All of my Sandboxie processes work with all techs enabled, save "Start", that needs 2 disabled. Half of them work with Firefox... I could use 1-2 more for FF alone, but it breaks some SBIE functions if I do. All enabled and Flash & plugin-container both work fine, which is good to see. Pidgin also works fine with all, as does VLC.

Now I'm gonna test how some of my start up processes handle them, one at a time. I know svchost takes to them just fine. But since none of the others ever face the internet I'm not sure I should even bother.

If you really do go through with that project please keep us appraised of your progress in here.

 

I know I always prefer simplicity. Also, even without EMET, regarding that foiled exploit attempt I referenced the other week... my software DEP gave me a warning via a pop-up box. First time I've ever seen it in my life. From what I recall it looked like a black command line box that said DEP was terminating the program (Pidgin Messenger) because it had become unresponsive. I've had programs become unresponsive before though, and DEP never did that. I use Comodo's task manager (in D+) to kill them. I've yet to see it fail to kill something in fact. I wonder if it employs the same methods Kill Switch does?

Also, if I had known a new EMET was planned for release so soon I'd have just waited a bit more. Now I'll have to uninstall this one. I'll stop testing my apps + techs out now and wait for that one.

 

@luciddream

Finally? LOL. Welcome to the EMET club in Wilders.

I don't know if you noticed but I tried my best to convince you to make the jump...I'm glad it wasn't in vain. Seriously though, what's stopping you from installing .NET 3.5 or higher? Tried it and it sucks or you're just trying to play it safe?

P.S. Sorry...it's been long since XP days. I can't remember how .NET fares on XP. I used to be in the 'no .NET' crowd too back then for the most part.

 

Well up until a couple weeks ago I was still on a Dell Dimension 3000. And on low specs .NET FW is bloat personified on XP. Now with an Inspiron 530 with a Core2Duo E8300 and 4 GB of RAM I can absorb the hit much better.

Even so, I'm a believer in limiting attack surface as much as possible. And nothing else I use requires .NET FW. So I was weighing if it would be worth it to add extra attack surface, especially something that's been riddled with vulnerabilities over time (.NET FW), to get whatever benefits EMET would offer me... which on XP is not as much.

So that's why it was a decision making process for me. And quite frankly I'm still not completely sold that it's worth it. I mean I've never been compromised in all my time without EMET. The 1 exploit that ever attempted to nail me was turned back by software DEP + Sandboxie.

And as to keep the surface as small as possible, since EMET requires only .NET FW 2.0, that's all I'm putting on there... fully patched v2.

But one thing I've learned for certain throughout this ordeal is that those other so-called alternatives I considered to try to avoid putting .NET FW on my box are not really legitimate options at all. WehnTrust will conflict with any other form of buffer overflow protection you have on your box, which most FW's/HIPS products will have these days, and I'd trust it over a 5 year old product. And NEMET just flat out doesn't work as advertised. It sounded great in theory, but in practice it was a whole nother story. If that guy would only release it with his own .dll files that I'm sure he created (but won't release)... it'd probably be an awesome product. But as it stands he's probably the only person on the planet able to enjoy those mitigation techniques on XP without having to resort to putting .NET FW on his box. Must be nice to be him... unless someone else emulates and improves upon his model some day.

Something like that, that actually works, without a .NET FW dependency... with EMET 3.5's (app) mitigation techs, would be awesome beyond description. I'd Knight the person.

 

You can uninstall all the .NET Framework packages and remove the traces afterward and EMET will continue to function just fine as long as those conditions are met that Larry mentioned... and that AppPatch folder stays intact even when using Revo's advanced uninstall mode for them.

So I've found my method of adding EMET without taking on the surface of .NET FW without having to fool around with less than reliable "alternatives". I'm now enjoying EMET without .NET FW... mission accomplished.