Security software can reduce effectiveness of DEP/ASLR

Read my edit. By definition you're right, it does increase the attack surface, but in reality, you're wrong, because of the functionality it provides.

Err no, *cough* PatchGuard. This only affects 32bit versions of the O.S., and since when is the kernel an internet facing application? I assume you mean using an Internet facing application that has kernel hooks, sounds silly to me.

Anyway, not gonna beat my head against a wall with you about this again.

 

So by definition ie: inherently I'm correct but somehow that doesn't apply because... you don't want it to?

Yeah, you're very confused.

Cool, I'll stick to my industry accepted opinions/ standards.

 

It doesn't apply because of the program we're talking about, EMET. You could inject a DLL into a program with one line of code that prints "Hello World". By definition you're increasing the attack surface, in reality you're not as there's nothing to exploit. Simple as.

Seems I misread what you said to mean the security software people are using is increasing the attack surface with kernel hooks, rather than you requesting security methods to be built into the O.S. which they already were when 7 was released (ASLR/DEP/SEHOP), short of new ones like BottomUpRand, etc, which will probably be in Windows 8. My apologies.

 

Yes, clearly the same thing.

EMET is not some single line of code. It is never good to add to an attack surface. Especially when it's a closed source application.

It is not only that EMET's interactions with applications are bad, though they could be, but the addition of EMET itself increases the attack surface and there are now that many more attack vectors. Why you think that because it's not internet facing matters I don't know - attacks can originate somewhere and end up somewhere else.

Anyways, the fact that security is being handled outside of the kernel is inherently bad but I don't think I'll be able to explain that... but...

Security shouldn't be handled by both the kernel and 3rd party applications, that only serves to complicate things and complications lead to vulnerabilities and bad policy.

 

Yup. I didn't mean kernel hooks I mean that Windows should be baking it straight into the source code and compiling these things with it. Another downside to closed-source.

I would love to see bottom-up rand and others supported by default but I wouldn't expect it, I've heard of some incompatibilities with it.

 

Well I don't expect 3rd party programs to support it, as we both know, many still don't support DEP/SEHOP . Though I'd be surprised if system files themselves (probably even IE10?) didn't support the functionality in EMET 2.1 by default.

 

I wouldn't bet on it. I don't think any browser currently supports bottom up rand natively but I haven't looked into it.

We will see if the OS itself supports at least the implementation but, again, (without EMET) I wouldn't bet on it.

 

Re - Buffer Overflows

If you run ProcessMonitor from SysInternals, you "might" be surprised at how Many of these you see for your Programs, including AV etc

Re - DLL Injection

ProcessGuard can block these, combined with not allowing rundll32.exe free reign if set to disallow or prompt in PG

 

Read here: http://blogs.technet.com/b/markrussinovich/archive/2005/05/17/buffer-overflows.aspx

In that article it's mentioned Filemon and Regmon, but it would apply to Process Monitor as well.

 

@ m00nbl00d

Good catch, Thanks

 

DLL injection is useful as hell though.

 

if there's a security hole, all we could do is try to mitigate the problem and wait for an update/fix. stop adding unnecessary stuffs.

My favorite way of handling things as a home user is...
...Just don't let anything execute unless sandboxed.

armed with knowledge of staying away from risky things... it's very safe.

 

And Konata joins the discussion . Nice to see you in here.

 

I'm about to sleep and just thought about saying good night to everyone in here

 

LOL Konata. Sleep well

 

That picture encapsulates exactly (it's not a picture that shows only the partial scan results but the full scan results) the differences between the baseline scan and the scan run after EMET was installed. The picture shows there are very few alterations made, and none that appear serious to the O/S after EMET is installed. BTW, the tool is the one used by Microsoft's Internal Product teams to analyze alterations made by installed software to the O/S.

I'm not suggesting EMET is the gold standard we should apply to mitigate security issues, only that my comments reflect on the ASA scan results on it, which clearly show there are few in number security issues in EMET.

 

I'm not saying the tool isn't useful, it's very useful. Seeing that a products config files are stored where anyone can touch them is great - more products should have a look at it.

But it definitely does not cover things like "Is this product vulnerable to X" and it wouldn't say "Oh it loads a .dll into the browser, which breaks DEP/ASLR" you see? It covers the programs attack surface but only to a very limited extent.

Still a cool program, still really cool to see the results.

EDIT: And my issues with EMET expand well beyond the fact that it increases the attack surface (EMET's a great example of a program expanding the attack surface in a way that this analyzer wouldn't pick up.)

When you analyzed EMET had you changed settings or forced any applications to run with it?

I'm wondering if it's just that it couldn't pick up on it because the settings weren't there or if the machine just doesn't detect those kinds of additions to the attack surface - I'm betting on the second.

 

I was actually defending the results of EMET, LOL, could be I misunderstood your previous comments As for a tool that could display those type of results you mention, that would be cool. Maybe one day we'll see it - hopefully A tool like it could help place some healthy pressure on coders to clean up the sloppiness in their programming efforts.

Yes, i placed ~ 10 programs into EMET before running the analyzer.

 

Honestly in your case I would be more worried about the issues your 3rd party security software has that are not picked by the scanner than EMET. Just saying

 

As I figured - it's an issue with the analyzer/ a choice not to bother saying "Hey, you're adding to the attack surface."

It would be a huge and unrealistic process to have a program created that can analyze your system so thoroughly as to predict how the attack surface that those programs add on to can be exploited.

 

I would love to see that so some of them can stop being so lazy

 

Not sure what you mean?

 

You bet, but no doubt the bottom line is more important than efficient coding to most of them They will place tons of effort in making the GUI look shiny and attractive, as this $ell$. One has to admit that most of the GUIs in these security products look might fine, lots of eye candy

 

As you stated before there are issues not picked up by scanner. I'm saying I would be far more worried about the unseen issues your 3rd party software has then the unseen issues that EMET would have.

 

Yea tons of eye candy but for what to just look pretty, but not protect efficiently bah . I prefer efficient coding over eye candy any day. Although a nice GUI would help usability