The Case of the Insecure Security Software

re: The Case of the Insecure Security Software

rivet — Wed, 20 Jun 2007 05:56:52 GMT

Did you only find flawed security models in third party applications or was there numerous findings in the baseline OS?

I work in infrastructure for a software developer, so I'll be passing this along for consideration.

Thanks as always

re: The Case of the Insecure Security Software

Ryan Russell — Wed, 20 Jun 2007 07:58:36 GMT

Thanks for the tool. I found a potential problem in a couple of minutes.

I get lots of output for Objects on 32-bit XP, but 0 for 64-bit XP, no matter what user or group I try. Objects not working on 64-bit?

:: Binary Paradox :: » Blog Archive » Re: The Case of the Insecure Security Software

Wed, 20 Jun 2007 22:37:51 GMT

PingBack from http://blog.binaryparadox.net/?p=35

Trovare punti deboli in Windows con AccessChk at bufferOverflow

Trovare punti deboli in Windows con AccessChk at bufferOverflow — Thu, 21 Jun 2007 00:59:17 GMT

PingBack from http://www.bufferoverflow.it/2007/06/20/trovare-punti-deboli-in-windows-con-accesschk/

re: The Case of the Insecure Security Software

anonymous — Fri, 22 Jun 2007 04:37:51 GMT

D'Oh, this is about how much news? Some year-old examples:

Security software from G-Data gives Everyone-FullAccess on its install directory and some registry keys.

WebDrive, FTPDrive and Novell NetDrive set NULL DACLs on their service and driver.

The NVidia ForceWare Driver gives Everyone-FullAccess on some keys in HKLM\SYSTEM which allows a user to DoS the system by writing garbage there. Additionally, the control panel uses a shared section for no good reason.

DeviceLock, at least until version 5.76.1, gave Everyone-FullAccess on \Device\HarddiskX objects if the access list contained as least one allow entry (and other totally removed any access, even to administrators). Hurray for "dd if=\\.\C:"!

I could list many more examples...

@rivet: Of course in the baseline OS there are only miniscule violations, f.e. some Full and Create access in some HKCR\CLSID\{CLSID}, but nothing serious. Microsoft isn't dumb.

re: The Case of the Insecure Security Software

markrussinovich — Fri, 22 Jun 2007 21:01:25 GMT

> I get lots of output for Objects on 32-bit XP, but 0 for 64-bit XP, no matter what user or group I try. Objects not working on 64-bit?

That's a bug that shows up only on 64-bit XP. I'll be posting an update in the next few days that addresses it.

re: The Case of the Insecure Security Software

Davis — Tue, 03 Jul 2007 23:42:49 GMT

I think that third party software not cause most of Windows crashes, but also creates very many security flaws.

For example a driver creating device object (for example meant for interface with service) accessible to everyone can be very dangerous.

re: The Case of the Insecure Security Software

anonymous — Wed, 04 Jul 2007 05:25:56 GMT

WTF? 3 out of 8 comments are the PingBack SPAM. Why doesn't Technet setup a filter that filters this SPAM? It's trivial to identify.

re: The Case of the Insecure Security Software

AlexC — Fri, 06 Jul 2007 15:51:48 GMT

What Mark has pointed out is quite a general practice for many companies that need to migrate their software to the new OS.

The developers do really go easy way in the most cases. However, that is so not because we're lazy, but mostly because there're at least too reasons for that, as to my experience:

1. The companies do not wish to involve much budget into support of a new OS version and push hard to make the software run with the same experience (as on the previous OS version) in a short time frame. The marketing and top management people are naturally interested in implementation of new competitive features rather than in investment of grinding/tuning existing functionality which might become broken by an up-coming OS but maybe quickly "healed" in the way described by Mark.

2. The companies are forced (for some or another reason) to support previous versions of OS, at least those that are still in support from Microsoft. IMHO, Vista is great about many new things in many areas. As a sys-engineer/architect and developer (by spirit), I would certainly love to re-design the software in my abode to use Vista's features and style, dropping out not modern and aged things. Yet, to meat high level goals, the interests of the company does not always coincide with my wishes.

These are not complains, just my view on things, and having said all of that, I think Microsoft still tries to do a good job of forcing apps to be compliant to new OS version by running misc Logo programs. But I'd like to say that the "Certified for Vista" test cases do not mention such/similar checks for the software as Mark describes, even though it enforces such details as manifests, code signatures, etc. I'm not sure what rules "Designed for Vista" Logo program imposes - I did not work with that, but it might be worthwhile to update the Logo programs with Mark's prescriptions. IMHO, it will promptly force the companies to resolve the mentioned holes in their software, because logo-compliance is a matter of business, making the top management take it into account.

P.S. I don't belong to any security software companies.

re: The Case of the Insecure Security Software

Rene Snajder — Mon, 09 Jul 2007 10:24:30 GMT

Dear Mark!

This is a little Off-Topic but since I do net receive any response when writing to you an e-mail, I'll try this way.

I experienced a nasty bug in the command line tool handle - which is in my case more useful than Process Explorer.

The bug is reproducible on every Windows XP System.

Try to open a txt file with excel. Excel will create you several *.tmp files in your %temp% directory. These files are called something like 37.tmp ore 74.tmp. Now as long as excel is opened there is a handle on that files. Process Explorer recognizes that handle. Handle.exe also recognizes it as long as you call it from inside the directory, or use the 8.3 folder names. If you use the full folder names with (with "" of course) then it won't recognize the handle.

So at first I thought: It might be because of the spaces in the folder name "Local Settings". But that's not the case. Create another file in the same directory (even with the same/similar filename), and open it with a process that puts a handle on it. Now check that file with handle.exe and it works, no matter which way you try it.

So it has to do something with the way excel opens the file, and the path using spaces or something?

Anyways, it would be great if that would be fixed. Wouldn't it be worth a small investigation, and a blog entry ;-)

re: The Case of the Insecure Security Software

Jody Cairns — Mon, 09 Jul 2007 18:11:49 GMT

I love these articles, even though I have little interest in Windows; it's the technical, investigative techniques that makes for compelling reading. Thank you!

re: The Case of the Insecure Security Software

markrussinovich — Tue, 10 Jul 2007 20:12:14 GMT

Thanks for the feedback, Jody!

re: The Case of the Insecure Security Software

jawz101 — Thu, 12 Jul 2007 20:16:41 GMT

You rock Mark. This article cracked me up because I'm a bit frustrated with the AV companies with petty complaints about ASLR and whatnot. Bottom line: Application Developers everywhere need to go back to school. When doing research for a project on improvements in Trustworthy Computing, SDLC, Vista, and just hanging out on your site, Channel9, & IT Showtime I've really appreciated how you all are handling business.

Bottom line: It's nice that an hour of your research leads to 1000's of hours of training and development for those who need to get with the times. That just goes to show how 3rd party app developers never used their 3 years of Vista CTP builds to their advantage

re: The Case of the Insecure Security Software

PhilW — Wed, 08 Aug 2007 01:56:10 GMT

A common reason for lowering security on the Program Files folder for an app is that the app creates data files in that location, and limited users can't create files there so....

The reason often seems to be sheer laziness. It's too easy to use files ("myfile.txt") without any folder name, instead of a proper location with a CSIDL and too much trouble to change the app.

re: The Case of the Insecure Security Software

confused_by_ms_security_model — Wed, 20 Feb 2008 23:21:59 GMT

I think the problem is plain and simply that the security model is too complex and hard to use effectively without just disabling it. For example I worked on an app that had to use secure registry keys, and it was a real bitch doing stuff that was even moderatly more complicated than the examples you could find on MSDN. Even there the pickings were slim, with useless or buggy example code, and the like.

If the security model is complex, requires a lot of knowledge and use of complex apis and interfaces and is poorly documented on top then its hardly a surprise that people mess it up so regularly.

If MS wants to improve the general security of their ecosystem then they really need to expose simpler API's and provide MUCH better documentation. Every example that has possible security implications should be coded securely, and be extremely clear in how the security aspects work.

People cut and paste code and then go from there, maybe they shouldn't but they do, especially when working on new material, and if the examples are crap, well then thats what gets rolled out. Ive seen this elsewhere, just by updating sample code in a scripting languages documentation to use "best practices" resulted in a general improvement of the whole ecosystem.

re: The Case of the Insecure Security Software

Martin Smith — Tue, 04 Mar 2008 02:05:49 GMT

@confused_by_ms_security_model

Absolutely agree!

re: The Case of the Insecure Security Software

Marcelo E. Sauaf — Tue, 08 Apr 2008 23:39:01 GMT

"simply that the security model is too complex" - anyone who can not deal with security INHERENT complexity (not so far really, in the case YOU used Visual Studio) might not be in development BUSINESS.

"People cut and paste code and then go from there" - laziness was never compatible with quality and professional attitude. Let the market to pros, not hobbysts.

Anyone who accepts to work in "piggest" conditions for not having another option to get a salary might be in other market but IT. Those people are the peskies who assolate the users, at all, when comes to them use their cheap stuff. Further, write a SECURE app for low price is UNREASONABLE, even foolness. Valet parking makes same money, no mental pain.