Security software can reduce effectiveness of DEP/ASLR

Thank you.

 

Hey wat, how about microsoft's own security essentials

 

Rife with issues LOL! Although I guess in some defence it's the TrustedInstaller rather than Everyone that has a lot of access rights.

Link is here: -http://www.megaupload.com/?d=OSFB6SWB

Too many issues to easily fit into a 300kB or less file. Darn Wilders file size limitations

 

Thanks wat. Microsoft should be ashamed of themselves for that many issues LOL. I don't give them an inch of leinancy

 

A lot of that looks normal to me. TrustedInstaller so it can, you know, update itself... others for example "MsMpCom by everyone", so everyone can use the update service.

Anyway, Windows 8 is supposed to have SmartScreen built in, that coupled with IE10 will make me try Windows 8 without any AV. The first time using Windows without AV since the 90s.

 

Well whether they look normal or not, I just wanted to see what results Attack Surface Analyzer would show for MSE and wat was kind enough to scan and post his report.

 

I'm more than happy and interested to see opinions posted by others. I don't know enough about this stuff to really understand how severe the "Attack surface" is. The results are there based on the ASA scan for everyone to view and formulate their own opinion on what it alls means. The more knowledge someone has about this stuff, the more informative the explanation could be as a result.

From my own limited point of view, I'm assuming "Everyone" is potentially more dangerous than TrustedInstaller, and then it probably depends on the directories that allow these rights on how potentially dangerous things could be. After all, there are already a number of user space directories that malware can write to anyway, without having to depend on the liberalness of a security products directories.

One more factor for me in determing how good a security product is, is how stable it is. For instance, trying to close Kaspersky pure in my test resulted in an obscure "error at location 00x000...blah blah blah" pop-up. It seemed rather unstable to me right of the bat.

This latter reason as well as potentially introduced security holes and performance degradation are primarily what drives me toward using what's already built-in to Windows.

 

Well wat I know the performance degradation (from usage of av, etc.) was a big decision in my switch to using built-in Windows security. I noticed the speed difference immediately after switching to a built-in Windows security.

 

Yes, Everyone is more dangerous than TrustedInstaller.

Some of these are non-issues (like if it creates a temp file that it uses once and that temp file is writable by everyone - just an example) and some aren't. I'm still curious to see anyone actually exploit this ie: change config through these files.

 

Yes I can see some being non-issues as well. But for the ones that are not, its nice having the knowledge and deciding what to do with it.

 

Another one hot off the press This time MS' EMET 2.1. Excellent results by the looks of things. It easily fits in a Snagit capture

BTW, just a reminder I'm running these scans in a Win7x64 vm.

 

I think Google Chrome would beat them all? After all it does install to user space. lol

 

Ha-ha...maybe I used the GoogleUpdater recently and installed it to Program Files instead. Of course it still places user data under my AppData\Local directory.

 

Rut oh. Time to stop using EMET, j/k

 

I would ignore any item in an Attack Surface Analyzer report that mentions "tampering by NT SERVICE\TrustedInstaller," since this is part of the operating system.

Based on wat0114's report, I installed Comodo Internet Security v4.1 in a virtual machine. Then I logged in as a standard user, and was able to modify keys and values within HKEY_LOCAL_MACHINE\SYSTEM\Software\COMODO\Firewall Pro\Configurations using Regedit. CIS lists HKEY_LOCAL_MACHINE\SYSTEM\Software\COMODO\Firewall Pro\Configurations as a protected registry key in its user interface. Maybe CIS allowed the changes without prompts because Regedit is a "safe" program?

By the way, AccessChk and Windows Permission Identifier can audit registry keys.

 

Seems likely.

CIS protects all of its own registry keys, I know that much. IDK about its own files.

 

Thank you MrBrian! Your input is appreciated.

*EDIT* as is the input of anyone else who wants to post Please do. I encourage it.

 

All this testing with Attack Surface Analyzer tool is interesting, but perhaps it could be moved to a dedicated topic, as it is not about security software reducing effectiveness of DEP/ASLR by loading DLL's into explorer/browsers.

I already tested some products loading DLL's that don't support ASLR into explorer.exe after reading Didiers blog about it, but now I read that its not just explorer.exe but also the browsers and two major companies are found "guilty," I concluded that this happens on big scale so I did some larger test. I tested numerous products and checked if they loaded DLL's that don't support ASLR into explorer, IE and Firefox. Here are my results:

 

Very informative.

I'd just like to add the following, since I decided to take a look at it. Spybot S&D also loads a DLL to Explorer and IE, which has no ASLR. If I still remember well , I believe Spybot doesn't support ASLR, at all.

I asked at Spybot's forums why not... yesterday. Still no answer. I just hope that version 2 will support it.

 

Thank you for sharing your results Boerenkool. Very informative indeed.

 

Interesting. This is why I use EMET on Avast! and Prevx. I checked with both company's and both said their are no known issues in doing so. Comodo apparently has issues though. Maybe it's time to add Sandboxie to EMET.

 

The issue raised here is security software injecting DLLs into OTHER programs such as your browser. Having your browser in EMET is all you need to solve this.

Going nuts and adding all your security software to EMET isn't going to benefit you and will probably create more issues than it solves.

 

LOL just add every program you run on your pc that willl solve it lmao But in all seriousness that will definitely cause unnecessary issues. I agree with you elapsed.

 

lol no, the issue here is that third party security software gives rise to more exploits - the fact that this third party also breaks basic security protocol via .dll injection is just highlighting that fact.

EMET is just as guilty as the programs mentioned in the first post - the fact that it works is how we excuse it and say "well it's a fair trade."

As I've said before, EMET increases attack surface as does (literally) any executable code on your computer.

 

Even if you don't agree about what Elapsed was saying. One thing he said is true. Adding security software to EMET will cause more issues than its worth.