Security software can reduce effectiveness of DEP/ASLR

[funkydude]

Originally Posted by Hungry Man

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

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.

Originally Posted by Hungry Man

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.

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.

[Hungry Man]

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

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.

Yeah, you're very confused.

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

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

[funkydude]

Originally Posted by Hungry Man

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

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.

Originally Posted by Hungry Man

Yeah, you're very confused.

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.

[Hungry Man]

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.

[Hungry Man]

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), short of new ones like BottomUpRand, etc, which will probably be in Windows 8. My apologies.

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.

[funkydude]

Originally Posted by Hungry Man

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.

[Hungry Man]

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.

[CloneRanger]

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

[m00nbl00d]

Originally Posted by CloneRanger

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

[...]

Read here: http://blogs.technet.com/b/markrussi...overflows.aspx

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

[CloneRanger]

@ m00nbl00d

Good catch, Thanks

[Hungry Man]

DLL injection is useful as hell though.

[Konata Izumi]

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.

[1chaoticadult]

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

[Konata Izumi]

Originally Posted by 1chaoticadult

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

[1chaoticadult]

Originally Posted by Konata Izumi

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

LOL Konata. Sleep well

Originally Posted by Hungry Man

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.

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.

[Hungry Man]

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.

Originally Posted by Hungry Man

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.

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.

Originally Posted by Hungry Man

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?

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

[1chaoticadult]

Originally Posted by Hungry Man

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.)

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

[Hungry Man]

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

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.

[1chaoticadult]

Originally Posted by Hungry Man

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.

Originally Posted by wat0114

A tool like it could help place some healthy pressure on coders to clean up the sloppiness in their programming efforts.

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

[Hungry Man]

Originally Posted by 1chaoticadult

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

Not sure what you mean?

Originally Posted by 1chaoticadult

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

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

[1chaoticadult]

Originally Posted by Hungry Man

Not sure what you mean?

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.

[1chaoticadult]

Originally Posted by wat0114

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

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