Security software can reduce effectiveness of DEP/ASLR

SRP/AppLocker won't prevent shellcode from running, although it's true that SRP/AppLocker will probably in most cases block the next stage of the exploit. Also, remember that SRP/AppLocker have some holes by design.

In my own case, if I were ever to get (or already have) malware, I would guess that the most likely culprit would be a download that I thought was safe but wasn't. Additional security software might help nab the malware before or after installation.

Funny, that was my thought too .

 

Yea he's Hungry for discussion

Although thats the case MrBrian, but isn't it rare that something would exploit that vulnerability as oppose to the vulnerabilities seen in 3rd party security software?

 

Haha actually this topic reminded me that I'd had a similar topic on the EMET board. I was talking to a security researcher friend and we couldn't come up with a reasonable excuse for Microsoft not to build it into the kernel so I decided to ask.

 

Very true and understood, but if you weigh the benefits of the security they do provide, as well as their efficiency and stability to co-exist in harmony with the O/S, against the odds of something present day breeching those defenses, it's a pretty darn appealing approach, at least in my limited point of view

Most likely your level of technical competence and security moxy will prevent this from happening anyway

In all seriousness I found the responses quite interesting. Maybe I'm mistaken, but it seems the one fellow suggests EMET is more valuable for pre Vista/Win7 O/S'?

 

It's no more or less valuable for XP, Vista or 7. It's just the fact that it enables more for XP, it'll bring XP (an older OS) up to and beyond Windows 7 standards, just as it brings Windows 7 standards slightly further than their default.

So it's a great tool for XP, which just isn't supported much.

Maybe, maybe not. It's never a good idea to bet on yourself to be cautious 100% of the time in my opinion. Human error is a common term for a reason.

 

I haven't read about exploits that try to bypass SRP/AppLocker by using the Microsoft-designed holes, but then again I haven't looked much either.

 

If SRP/Applocker were popular you'd see them. Already we have 25% of the malware out there (reportedly by MS) bypassing UAC because of the weaknesses of the Windows 7 default level.

 

I find AppLocker appealing too . If one wishes to put all of one's "security marbles" (so to speak) in SRP/AppLocker, I guess it would logically follow that one needn't bother with using a standard account either.

 

Do you have a reference for this? (I had been wondering why more malware didn't take advantage of Windows 7 default UAC level.)

 

But I combine AppLocker with a Standard account plus EMET and some other minor security enhancement, so there's no putting all the marbles in to one place.

 

Right - the point is that you don't rely on only AppLocker either (neither do I).

 

situation:
I open my browser go to some shady site with exploit to bypass security due to the lack or improper implementation of ASLR/DEP/SEHOP in my processes.

How likely am I going to get exploited with my setup?

Standard User Account set to automatically deny UAC(max) elevation requests.
SRP
EMET system-wide setting only.

 

SUA is powerful, elevation exploits in Windows aren't that frequent that I know of.

SRP is bypassable but it's so unused that any automated attack will be thwarted

EMET.dll is enough to break pretty much everything. System wide settings alone are far weaker but pretty good.

 

Can't find the 25% statistic.

http://www.computerworld.com/s/article/9218916/Malware_turns_off_Windows_UAC_warns_Microsoft

But MS released a statement a while ago.

 

How about this for a response:

If you were to place your system with that setup in my hands, and I used it exactly the same way I use my own, I can confidently say it is very unlikely it would get exploited

 

I think thats the point , is to have several layers in place so one doesn't just depend on one single layer only.

Agreed.

Ok thanks.

 

If you ran into an exploit, SRP would probably stop it before any real damage was done. If you want even better protection though, consider creating EMET app rules for your browser process(es) (and Java processes too, if your browser can use Java).

 

you mean most exploits does not need elevation?

 

Thank you.

By the way, UAC Windows 7 with default UAC setting, when used in an admin account, is indeed bypassable as of the final Windows 7 version. I didn't try the bypass with SP1 yet though.

 

No, you can have an exploit that runs arbitrary code via some other program. That's certainly dangerous.

What's more dangerous is when you've got a virus with admin rights as well, which would take a Windows exploit. Hard to come by on a default installation, harder when you remove admin.

 

What about when UAC is used with always notify (max level)?

 

Are you sure about that? Are you sure that EMET provides more to Windows XP than to Windows Vista/7?

I don't have Windows XP, and therefore could never run EMET in it, but according to the images at Rationally Paroind's EMET article, SEHOP and ASLR aren't available for Windows XP.

http://rationallyparanoid.com/articles/microsoft-emet-2.html

 

System wide settings are disabled for XP because they aren't supported by the OS. EMET.dll can still force them.

Suddenly you have ASLR (pseudo) and SEHOP on an XP machine. That's a big jump.

 

That's fine.

If you want to test it yourself, see https://www.wilderssecurity.com/showpost.php?p=1830523&postcount=44.

 

It is most certainly bypassable in SP1. Nothing's changed. The whitelist exists throughout the lifetime of Win7.