Mitigation techs available on XP

What of the EMET mitigations available (on the latest 3.5 build) are available on XP?

Is it only DEP, ASLR, & SEHOP? Because I thought I remembered seeing EMET installed on an XP box and seeing things checked for other mitigations too. Or will it allow you to check them even if they're not really working? I'd think doing so could potentially cause issues though, so I'd like to only have enabled what really can work.

Just in case I can get WehnTrust working right (which adds ASLR & SEHOP to XP), I want to know if there'd be any benefit to having EMET instead. Otherwise I'd rather not have to install .NET FW, which isn't needed for WehnTrust.

Also I'm installing EMET on a friends (XP) machine, and want to know if there's any benefit to him of using 3.5... or even 3.0 for that matter over 2.1 Is there anything in the newer 2 that can even be used on XP compared to 2.1? If not I'd rather just put 2.1 on for them since it seems to be lighter on XP and has no tray icon.

 

I think I recall hearing that's there's only 1 mitigation technique you can't get on XP that you can on the newer OS's since. But can't remember which one it was. Also don't know if I heard correctly.

And also one that's only possible with 64-bit OS's, if I recall.

It's all a blur to me now though. And judging by the lack of responses, I'd say I'm not alone there, lol.

 

ASLR isn't available on XP.

Be wary of programs stating they offer ASLR. Many offer "ASLR Alternatives" which are nothing but trivially bypassed pseudo-mitigations.

 

Thanks so much for chiming in HungryMan... you saved me a lot of time & effort messing around with WehnTrust.

I'm going to install EMET when XP reaches it's EOL. Hopefully by then v3.5 will be out of beta. As once XP is no longer being patched such a tool would become very useful towards safely extending it's life. Because I have no desire to use any Windows OS since XP. Unless that changes, if/when I feel it's no longer viable to use XP I'll be moving on to MAC's.

That's pretty good though... that XP can take advantage of all the mitigations except ASLR. Now I'm trying to recall what is only possible with 64-bit, if anything?

 

Without ASLR things like the Anti-ROP techniques become way less useful, as they only protect very specific areas of address space, and ASLR is meant to protect virtually the entire address space.

You'll prevent legacy attacks, but that's all. I wouldn't recommend XP, but that's up to you, just want the information out there for you so you can make an informed decision.

 

Yeah I know. My reluctance to use post-XP OS's is an informed decision though. IMHO you can make XP Pro the most secure Windows OS to date, though it certainly doesn't come out of the box that way. I've explained my convictions regarding this in the past and don't want this thread to devolve into another argument of that nature though. To each his/her own approach. Taking my attack surface into consideration the chances of EMET ever protecting me are extremely remote. Though once the patches stop coming I see far more potential benefit.

In my entire span using XP (8 years or so) I just last week ran into my first potential attempted attack. And it was plain old software DEP + Sandboxie that stopped it. I get the feeling DEP is the most important of the mit. techs by far, and that combined with sandboxing all internet facing apps not much can get by it. The sandbox isolates it, then DEP terminates the app when in becomes unresponsive, then the sandbox is deleted. And that's that.

I appreciate the info.

 

Before dismissing Wehntrust's ability to provide ASLR on Windows XP you should seek some data to support the claim. I have a hard time believing that the WehnTrust team is peddling snake-oil. Of course, the best thing for you to do would be to test it yourself in a VM (I know you won't be doing that based on prior posts).

I will have some time tonight or tomorrow to install EMET in a clean Windows XP VM for you. I can then get you a NEMET redeployment package you've been asking for. Just PM me your email and I'll send it over.

 

0stro, that's very kind of you. And how ironic... I was just coming here to say that after further review I'm not convinced that WehnTrust's implementation of ASLR is as bogus as was suggested above... after talking to a few other people who recommend it (including the developer of NEMET). Not to mention seeing who developed WehnTrust... a very skilled individual. I'm hardly ready to close the book on it.

I was actually just about to say I'm going to go ahead and install one, or both. I think I was making the whole NEMET thing more difficult than it is in reality too. I'm not sure I even need that EMET .dll at all anymore... I think he may have remedied that situation and you can add apps without it. I was just going to install it to find out. But now I'll wait for that pack you so kindly offered, just in case it's not the case.

I was a bit confused though, in the post in here the developer made... it sounded like applying that redeployment pack installs EMET on your box too, which I don't want. Because then I'd need .NET FW too, and my mission here is to avoid that. Or will that pack only add the ability to add apps? That's what I was hoping for.

Maybe while you're at it you could see if you can indeed already add apps in NEMET without needing to go through any of that hassle?... The developer suggested in that post that he was close to making that a reality. And looking at the site, it sounds to me like you can indeed add apps. Though perhaps not with all the mitigations that say EMET 3.5 offers (that's the version I'd like, due to the added features).

It would be uber awesome if I could get ASLR through WehnTrust, and everything else through NEMET... here on my XP box without .NET FW touching it : ) That is my mission.

You're about to get a PM... thanks again, so much. I owe you one man. Some day I may have a license laying around for something you want/need, if you feel me...

 

@lucid,

the screenshots show all that I can see, at least, as being available in EMET for XP...

 

I'll still get you the redeployment pack for NEMET, but wat0114's screenshots confirm my suspicions that you aren't going to see any benefits on XP.

My experience with Wehntrust is something I've posted before. I tried it and didn't like that it was filling up my C:\ drive with a copy of every .exe and .dll file from my installs located on my D:\ drive. I understand why it was doing this, but I couldn't afford the drive space so I uninstalled it. If you have the space available, it should work well for you. I can't recall any other issues that I had with it.

 

Well yeah that's what I expected. That's why I'm hoping to get WehnTrust working to provide the ASLR & SEHOP (though I thought the latter was available on XP, I swore I saw it green before when I used EMET in the past). But oh well... I still see several other things available for apps that could be beneficial as well.

And if I can get WehnTrust working... I have everything in place anybody else would have. So really, nothing lost at all.

And yeah I have plenty of HD space... more than half of my 160 GB HD is free space. And I have very few programs on this thing, so that won't be many .exe's & .dll's in my case.

So yeah, it's definitely well worth it. In fact if I get both things set up the way I think I can I'll have it all.


P.S.- also, if you feel there's little benefit how come you're using it wat? And you may wanna give WehnTrust a look too.

 

Also, how come SEHOP is checked for the app rules if it's not available system wide? Does checking those boxes actually do any good for the apps?

 

Maybe of some interest regarding the effectiveness of EMET on XP is this Microsoft Security Intelligence Report - volume 12, where they tested 184 exploits against it...

The screenshot is a graph taken from the report.

 

But if nothing but DEP works on it, per your sceeny, and DEP is already there natively... how does it help?

That's my question. The two posts/screenshots seem to be in conflict with one another. It seemed in the first post you were suggesting it had little value to me. And now, you suggest to the contrary.

Is it the heap spraying, and app mits of that sort that make the difference then?

 

Also I wonder how many of those exploits succeed on my setup, with my hardening, a default deny SRP, Paranoid D+, restricted sandbox of all internet facing apps, etc...?

That test was probably done with just a default Windows install... things like Remote Registry turned on and all. Just bursting at the seams with vulnerabilities. That certainly doesn't remotely represent my situation, or yours either.

 

Honestly, I don't know.

I guess it's because SEHOP is at least available for individual apps?

Well, personally I believe the test results to be accurate, so EMET must somehow add protection value to XP.

 

Then it would have to do something it's not advertising, behind the scenes or something. Or those app rules, like heap spraying or whatnot make a big difference...

I believe the results are certainly accurate... but given a certain scenario that doesn't represent my real world situation remotely. Like a default XP install with things like Remote Registry & SSDP Discovery Service, UPnP, etc... all blasting away. Java installed. etc... Also DEP by default is opt in only, protecting no apps and very few/select services. So that test was done more than likely under the least ideal of conditions for XP.

I'll bet that on our boxes very few of those exploits work.

Still, since I plan on using XP past it's EOL, I see this tool being very potentially beneficial to me at that time... once the patches stop rolling in. So I'm going to do my best to pull this off and get all those mitigations in place.

Major props to both of you (0stro & wat) for your help.

 

Actually though, the test with EMET was more than likely done under the same default XP installation... so all of that is rendered moot actually.

That means the most logical explanation is something I actually theorized in another thread... that DEP alone makes a HUGE difference. They probably turned DEP to always on for the test with EMET. Whereas with the test without it it was in it's default opt in state, protecting very little.

I'll bet that's what it was. But the thing is... I have my DEP tweaked to always on already.

But still, those app mitigations could be quite useful. And as I said I'm determined to get WehnTrust working as well. So I'll get something out of it, and without adding the surface of .NET FW in the process.

 

Luddites of the world unite! Buggy whips ARE the future.

 

He who studies the past, has a better understanding of the future. If I can add what is generally considered as thE main reason to upgrade to a newer OS to one with a fraction of the attack surface... then count me in on the buggy whips too! The Amish aint no dummies. I'm gonna have my cake and eat it too here.

... try not to get too jealous ; )

 

I didn't say Wehntrust was snake oil, only to make sure you do your research, as there have been *many* programs for XP claiming similar things.

What Wat linked to was a simple study by Microsoft showing that 80% of exploits for XP won't work when you force the programs to use DEP. Because XP doesn't have ASLR disabling DEP is a matter of ROP for Opt-In. If you force DEP, the exploit will fail.

SEHOP also works, but not on a system wide basis, because it's not supported. It only works on an andividual app-based basis, IIRC.

I doubt Heap-Spray made a difference. If EAF is supported (probably is) it should prevent some as well

Anyways, on Wehntrust, this is what I had figured. PseudoASLR is possible on XP, but EMET doesn't bother with it because it's so limited.

http://seclab.cs.sunysb.edu/seclab/pubs/acsac06.pdf

That's why I said to double check on how effective it'll be =p

 

Was that in the text of the document? (I think I've read it before; seen the graph.) No, it shows 80% or whatever don't work, when using EMET, not just DEP. And lucid keeps saying that DEP makes such a difference (I say it doesn't), but he's NOT even using DEP without hardware support, despite what Microsoft calls it!

What do you mean? OptIn for DEP how? AppCompat database ("soft" like OptOut) or the app calling SetProcessDEPPolicy (permanent, no disabling)?

But yes, only having/using DEP or ASLR is not as effective as both together...

That's awfully ambitious thinking. If that was the case, we should have almost no working exploits now, since Vista SP1, what with ASLR and automatic permanent DEP with /NXCOMPAT (basically all modern stuff?).

Yeah (for lucid).

In no particular order, I'd think DEP (least), SEHOP, EAF, and HeapSpray "broke" the exploits in some combination. And that's exactly what EMET is supposed to do.

If it's visible in EMET on XP, it's supported. The only thing missing is "MandatoryASLR" (just DLL relocation according to first link below?). BottomUpASLR randomizes some stuff (heap, stack...?) that seems like what WehnTrust says.

I didn't look yet, is this "Dawson" something available, or just a test project?

Anyway, those comments... I thought addresses were supposed to be more random on 64-bit systems with the larger address space...? Or not?

See these links for more on (Pseudo-)ASLR:
So How Good is Pseudo-ASLR?
Bottom Up Randomization Saves Mandatory ASLR (EMET's BottomUpASLR)

 

Long post.

For reference:
https://blogs.technet.com/b/securit...ation-experience-toolkit.aspx?Redirected=true

I can't find the "80%" statistic I'd read at some point.

DEP being forced alone is enough to stop many exploits for XP. He probably does have DEP. Hardware that doesn't support it is ancient.

If you have a program using DEP an it is exploited an attacker can use ROP with SetProcessDEPPolicy to disable it and execute their payload.

Assuming the attacker is using ROP to disable DEP, and you have forced DEP on either system wide or through EMET the exploit will fail. Obviously more complex ROP chains have been created to execute full compromises from the initial stage one shell.

I doubt HeapSpray played any role whatsoever. But it's possible, and yes, those would prevent the exploits.

WehnTrust doesn't give much information at all as to what they randomize.

No clue about Dawson, they've just got the research that's relevant.

Yes, on 64bit ASLR is more effective.

 

Oops, I just checked that link AFTER writing the following post... (I thought it was a link to the same data as the PDF, but this is where I saw that chart.) OK, so /NXCOMPAT DEP isn't as common as I thought (and I had just seen this recently!), but for commonly vulnerable stuff, I think it is.

And using EMET there just to enable DEP? Come on! Set the system to OptOut and be done with it (exceptions if needed). Either way, for those apps, it won't be permanent without AlwaysOn.

Heck, in that case, maybe my DLL could be more useful than I thought, "just because" for DEP, even on the newer OSes. Even for 64-bit, for the 32-bit processes (since 64-bit ones are always permanent DEP, no exception, AFAIK).

Yeah, but he talked like it's that old. I gave the link in his other thread to a DEP Test program that will check whether DEP is effective or can be bypassed.

Right, but SetProcessDEPPolicy does NOT work if the DEP is permanent (the only kind there is if it's "opted in" by the app with that function). That only works if it's "soft" on, via Windows XP's OptIn ("essential" (and silly!) programs and services controlled by the AppCompat database) or via OptOut.

My trivial DLL will set permanent DEP on all processes unless they're opted out (explicitly or implicitly). Although I still don't think think DEP does much anyway, it's more of a "just because" thing.

Permanent DEP (can't be disabled) is present since Vista SP1 from what I understand (when /NXCOMPAT is encountered, ignored on XP), so why SO many exploits? Because DEP hardly does crap, I say.

BTW, EMET doesn't seem to set permanent DEP from limited testing, and neither does Windows system-wide -- unless AlwaysOn, or Vista SP1+ with /NXCOMPAT programs (so basically, everything, in practice).

Really about HeapSpray? I thought that was a more common technique. *shrug* I don't really KNOW which of the specific methods are most commonly used "gateways" (any stats?), I just have doubts about DEP.


Anyone ever seen a Microsoft bulletin where it mentions DEP as a mitigating factor (oh wait, yes I did a few years ago) or a workaround? EMET seems to take care of a lot of them (mentioned on the SRD blog) and it's been recommended in a few bulletins.

 

Are we not talking to default Windows XP?

DEP is bar-none the most important mitigation technique.

Because ROP was invented.

Again, DEP is the most important mitigation technique. Without it all others are useless, because the address space is executable.

The antiheapspray in EMET isn't that amazing or effective. It's just a pseudo-mitigation. HeapSpray isn't a hackers go-to, except when dealing with more sophisticated methods. Attackers like reliability too much.