Security software can reduce effectiveness of DEP/ASLR

It depends. I find it really stupid that security software doesn't already support the things that EMET would force by default. If a security software was compatible it should be added to EMET, security software is just as vulnerable as any other part of your computer.

 

I disagree. A security app makes ongoing changing to programming code and a single change or changes in that code can cause an incompatibility that in result can cause system instability. Plus even if I were to agree with your statement, it doesn't apply to me anyways, only to people who decided to install 3rd party security software on their pc such as yourself.

 

Yes, I realize that that's the way it is. I'm saying that the way it should be is that security programmers should be supporting something like EMET/ not even need EMET because they're programming a freaking security program haha make it secure.

 

I also just tested NIS 2012 to see if they finally fixed it and it passes on all 3 processes

This doesn't seem to work, I had explorer.exe, FF and IE in EMET and enabled the hidden option Always on for ASLR in EMETs system-wide settings, those DDL's loaded without ASLR still don't have ASLR according to Process Explorer.

 

Well we can say what should be all day, but that is wishing and hoping the programmers one day they will code these functions into their software even if we bash it in their brains lol. Seeing how I need my system secure now, I rather not worry about these issues and thereforce chose a different direction.

 

Of course. I don't run my security software with EMET. But considering that this topic is a discussion on how security software literally always increases the attack surface and sometimes can even take down other application defenses I think it's worth noting that many security programs don't do the most basic things to protect themselves.

 

Which again is part of the reason my I changed my direction in securing my pc. I decreased my attack surface and also gave my pc increased performance as well.

 

If you check out my post #61, I checked EMET and it came out looking pretty good. I don't have any problem using it to bolster the defenses a bit, although Boerenkool's last post kind of gives some cause for concern.

 

I also don't mind using EMET either, as the issues seem minimal to me especially considering two issues are dealing with trustedinstaller.

 

This tool is a VERY small picture. It shows a specific applications attack surface where logical vulnerabilities lie. There's more to it than what this is showing you. It doesn't go "Oh well when EMET.dll is loaded you can buffer overflow blah blah blah" or "When emet.gui is running you can crash it by using XYZ and use after free yourself some malware" or anything like that.

It's a very small picture and it only applies to what it can see.

 

Hungry, any tool we use is limited in scope, thats a given. How many times have we seen people discover vulnerabilities and exploits we didn't know existed?

 

Okay, so what does the "normal" person do? The OS obviously isn't secure enough, otherwise there would be no need for 3rd party security. So if 3rd party security opens up more attack vectors on top of existing flaws in the OS, what exactly do you do? What if you decide to balance things out by using security software that "passes" this attack surface analyzer, yet that software has reduced effectiveness (think AV/AS detections, less thorough protection)? You're still kind of screwed.

I'm looking at this discussion from a "I don't know a darn thing about security" perspective. If "Joe" pops in here and sees this, if his head doesn't explode from trying to figure out what the devil ASLR even is, he'll break out in sweat wondering how he's going to secure his system. Do you see what I mean? Personally, I think "tools" like this analyzer only serve to make the paranoid even more paranoid, but, at least it does show that loading down your system with anti-this and that doesn't make everything rosy.

 

I just want it to be clear that the attack surface this program shows is nothing compared to what can actually be exploited.

A few things.

For one thing you avoid it (3rd party) as much as possible. Instead of installing a bunch of side-by-side programs try to keep things simple.

When you do install 3rd party software see if you can cut down on the useless stuff it does - if it's starting up a ton of services.

Then try to mitigate with your own system built-in protection like applocker or integrity.

The tool's for developers haha all it serves to do on Wilders is get people to realize that loading up on security software isn't the best method for security.

 

No problem Hungry.

Agreed on all counts.

 

This is actually a post on the matter from another forum I frequent:

Basically, keep things off of your computer =p including security software unless you absolutely need it (ie; you see an attack vector that you can not possibly mitigate with internal-OS techniques and that attack vector is large enough to outweigh the additional attack surface)

 

lol yes, the only way security software is giving rise to more exploits is injecting unsecure software into internet facing applications such as the browser. Add the browser to EMET and you're fine. Unless you're talking about system local exploits for programs (viruses) already on the system to exploit.

What is EMET guilty of exactly? Injecting DLL's? Maybe. But that's how you deal with compensating for sucky code in other programs.

As I've said before, EMET does not increase the attack surface any more than any other non-internet program you're installing, as it's not internet facing. But please, keep on preaching your "facts", like the time you thought you knew better than Microsoft's engineers that coded EMET in the first place.

explorer.exe is not IE, iexplore.exe is IE. Process explorer probably only tags something as "ASLR" if the DLL actually has the ASLR tag (--dynamicbase=true) turned on.

As long as you see EMET.dll in the process you're fine.

 

Linux users don't really have to worry about this for the most part. Because it's open source the kernel can be compiled with all of the security software into it (the software is designed from the ground up for this, of course) and is therefor MUCH harder to bypass.

On top of this the fact that it's open source gives it a few bonuses - one being that everyone can look at the bugs, the other being that everyone can look at it and verify it does the job properly.

 

Agreed, however, due to MS policy of not making security tools version-wide, Home Premium (that would be me too) are denied a lot of "built-in" protection.

Lol, anytime Wilders' gets a hold of one of these things, it never looks good. People here will tear the thing apart, run scenarios akin to 2012 end of world scenes, and all sorts of stuff. I pity the "normal" person that comes across threads like these

 

Not any more and not any less.

You're literally wrong lol the FACT (yes, it's a fact) is that executable code increases the attack surface. Microsoft knows this, literally everyone in the industry knows this.

For some reason you (mistakenly) believe that attack surface has something to do withe the internet or non-native API's - it does not. If you add executable code to the OS it increases attack surface.

http://www.sans.edu/research/security-laboratory/article/did-attack-surface

" We can define attack surface as our exposure, the reachable and exploitable vulnerabilities that we have. "

Holy moly, sounds a lot like executable code living in userland!!! Who would have thought?

Not you I suppose!

 

http://en.wikipedia.org/wiki/Attack_surface

What's that? Attack surface is software in userland? You mean ALL software? Gosh. Just like I've said all along.

Not to gloat, but I've said this for a long long time. I stopped being lazy and got a source this time.

Paranoia can be healthy sometimes =p

 

*facepalm* where do 99% of attacks come from again? Oh that's right, the internet. We're home users here, not corporations. We need not worry about our own LAN's or system-local exploits. Our only attack surface is internet facing applications. Sigh.

 

lol yes, disagree with the industry accepted standard for the DEFINITION of attack surface

don't just concede that you're actually provably incorrect

EDIT: And when you're loading up .dll's like EMET.dll into your INTERNET FACING browser, yeah, you've just increased the attack surface of your INTERNET FACING browser.

So even by your own (incorrect) definition EMET increases the attack surface.

 

I'm not sure why you're changing the subject to "what the definition of attack surface is". Where did I argue that reducing the amount of code you run wouldn't decrease it?

What you don't seem to understand is that you can have a giant atack surface only visible to your system, as a home user, IT DOESN'T MATTER. What matters is the internet-facing code you run, and how it can be manipulated remotely. You can run all the offline crap you want AS A HOME USER.

That COMPLETELY depends on the type of code being injected. In the case of EMET, this simply isn't true. There's nothing to exploit in the DLL, all it does is enable system function like ASLR, already present in the system. If you were injecting Toolbar XYZ, you'd be right, but we're not.

 

Read the edit. EMET effects your internet facing applications attack surface just as much as the first posts programs do.

If something gets onto your machine via the internet and it's met with hundreds of exploitable userland programs that's an issue.

All of that security software people use should be built into the kernel and that's not just for reducing attack surface, it's because when it's in the kernel it's almost impossible to bypass it.

 

To your edit:

Not really. The code being injected is by some userland application. That's enough. It really doesn't matter whether it's enabling system-wide settings or not within the program, the attack surface of the program increases the second you add more code to it.

Not only that but by having security handled by user-land you allow for security to be more easily bypassed and, just as importantly, when that security is bypassed nothing happens ie: the applicaiton crashes and you're at risk. If EMET were bypassed and built intot he kernel the entire were system would crash (kernel panick) rather than you being compromised.

That's why EMET is poorly designed, but I still use it.