| Date: | November 22, 2004 / year-entry #400 |
| Tags: | history;when-people-ask-for-security-holes-as-features |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20041122-00/?p=37233 |
| Comments: | 39 |
| Summary: | If I had a nickel each time somebody asked for a feature that was a security hole... I'd have a lot of nickels. For example, "I want a file that all users can write to. My program will use it as a common database of goodies." This is a security hole. For a start, there's... |
If I had a nickel each time somebody asked for a feature that was a security hole... I'd have a lot of nickels. For example, "I want a file that all users can write to. My program will use it as a common database of goodies." This is a security hole. For a start, there's an obvious denial of service attack by having a user open the file in exclusive mode and never letting go. There's also a data tampering attack, where the user opens the file and write zeros all over it or merely alter the data in subtle ways. Your music index suddenly lost all its Britney Spears songs. (Then again, maybe that's a good thing. Sneakier would be to edit the index so that when somebody tries to play a Britney Spears song, they get Madonna instead.) [Minor typo fixed. 10am] A colleague from the security team pointed out another problem with this design: Disk quotas. Whoever created the file is charged for the disk space consumed by that file, even if most of the entries in the file belong to someone else. If you create the file in your Setup program, then it will most likely be owned by an administrator. Administrators are exempt from quotas, which means that everybody can party their data into the file for free! (Use alternate data streams so you can store your data there without affecting normal users of the file.) And if the file is on the system partition (which it probably is), then users can try to fill up all the available disk space and crash the system. If you have a shared resource that you want to let people mess with, one way to do this is with a service. Users do not access the resource directly but rather go through the service. The service decides what the user is allowed to do with the resource. Maybe some users are permitted only to increment the "number of times played" counter, while others are allowed to edit the song titles. If a user is hogging the resource, the server might refuse connections for a while from that user. A file doesn't give you this degree of control over what people can do with it. If you grant write permission to a user, then that user can write to any part of the file. The user can open the file in exclusive mode and prevent anybody else from accessing it. The user can put fake data in the file in an attempt to confuse the other users on the machine. In other words, the user can make a change to the system that impacts how other users can use the system. This sort of "impact other users" behavior is something that is reserved for administrators. An unprivileged user should be allowed only to mess up his own life; he shouldn't be allowed to mess up other users' lives. Armed with this information, perhaps now you can answer this question posted to comp.os.ms-windows.programmer a few months ago. |
Comments (39)
Comments are closed. |
Sounds like an Access database on a file share to me :)
People are lazy.
"Armed with this information, perhaps now you can answer this question posted to comp.os.ms-windows.programmer a few months ago."
Mhmmph. This is a dumb question. The poster really should have reexamined his horribly flawed design in the first place. Even without reading this article, I could see this is a dumb idea.
The common settings can be set by an administrative user, Whereas each individual user can customise those settings(saving their changes in HKCU)
This way, they change things to their preferences while not affecting every single other user.
The obvious answer to that question is to make all your users members of the Administrators (or Domain Admins) group ;-)
Like, DUH!
;)
OTOH, the developer isn’t thinking like a hacker and doesn’t intend to do harm, which is good.
OTOH, the developer isn’t thinking like a hacker and won’t write his code to be safe against hacking attempts, which is bad.
Not only can one user corrupt a world-writable file at will, they can do it in a way that exploits a buffer overflow bug in the application, and use this as a way to gain control of other users’ accounts.
OTOH, there are environments where you don’t care about security. My machine runs XP Home; I use one of three user accounts, depending on what I’m doing, so that I don’t get distracted by games while programming (for example). I share my music across all three users by putting all of my music in Shared Documents and setting up a junction point (like a symbolic link on Unix, but works on NTFS) for each user. My media player stores its database in a couple files in a subdirectory of My Music, so the index is shared too. It’s a bit hackish, but it works.
// My media player //
iTunes? I use the same junction-point hack to share its library between the 2 users on my machine.
I suspect though that even on a home machine with known users you still want to protect users from each other: who knows what nasty executables the wife/kids/friends/whoever have let in?
Someone should have told Microsoft…
Most of the folders under "Documents and SettingsAll Users" are writable by all users (on my default installations of 2000 & XP Professional). If we drill down to "Documents and SettingsAll UsersApplication DataMicrosoft" we find several programs with a "common database of goodies".
>> Armed with this information, perhaps now you can answer this question posted to comp.os.ms-windows.programmer a few months ago. <<
If you’re sure of the security consequences, look up SetNamedSecurityInfo().
ac,
On the (relatively uncustomized) Windows 2000 box I use at work, both the "All Users" directory and the specific directory you mentioned are writable only to members of the Administrators and Power Users groups. The group "Everyone" and the group "Users" have access to read, execute and list folder contents.
If you’ve got all of your users in the administrative and power users groups then you obviously don’t care much about security.
Brent,
Although Microsoft saw fit to hide the pretty security customization UI in Windows XP Home the command-line tool cacls ("Change Access Lists", I think) is still available, so you can give all three of your users write access to that specific file or directory. I’ve had to use this utility several times to help those who were foolish enough to purchase this cripped version of Windows to run old budget games which expect to be able to write to directories under "Program Files". (Fortunately, they aren’t foolish enough to perform everyday tasks as a user with Administrator privs.)
Correct me if I’m wrong, but won’t disabling Simple File Sharing in WinXP home allow the ACLs to reappear in the properties menu on the object, undermining the usage of cacls?
Why use an advanced, and widely unknown structure such as a junction point when just making the ACLs appear would do the job, and probably a lot better?
It’s true that on Windows 2000 "All Users" is restricted to Administrators & Power Users, but on Windows XP they relaxed the permissions so that Users can now write to "Application Data".
I don’t like it either…
Security is not everything, it’s simply not an issue for some applications.
I can see for many custom apps for small teams working on the same LAN, security/disk quotas are not issues people need worry about. Convenience and speed of development are far more important.
B.Y.: Hope you application breaks when Windows locks down more features in the future. Read "Writing Secure Code" dude, you’re obviously a newby!
Newsgroup poster: that’s why outsourcing is never really a good idea. :)
I think the environment where the user wanted this kind of almost wide-open access is similar to one where coworkers can look at each other’s desks and can even open each other’s desk drawers. If they abuse the capability then they should expect to get fired. Maybe this almost wide-open access is no worse than the presence of the computers already in that environment.
Of course it still would be dangerous to make it completely open. You don’t want to let every infected machine on the internet come in and write your files. This is why in Windows XP "everyone" doesn’t mean "everyone" any more, right?
If "everyone" access to a folder isn’t adequate for some reason, then the folder could be put on a FAT partition. Or the share could be put on a Windows 98 machine but that would be an act of desperation.
Of course you wouldn’t want to trust other machines on your LAN in a hotel room or restaurant or train station the way you might in your office. And even in your office you wouldn’t put that shared folder on a domain server or firewall server, you’d only put it on a file server.
A: What are you talking about? Both my home and work Windows XP machines have %HOMEDRIVE%Documents and SettingsAll Users set for read-only access to non-power users. This would appear to be the default.
Try it:
cacls "%HOMEDRIVE%Documents and SettingsAll Users"
A: the DACL you listed doesn’t allow a limited user to modify files created by somebody else (note that the write ACE for Users is Container Inherit only – it doesn’t apply to files).
The end result of this is that anybody can create files and folders under All UsersApplication Data but only file owners, admins and power users can modify them.
%systemroot%temp is another world-writable place, and it also has a DACL that serves similar purpose: allow all users to create temp files but don’t allow one user to read or modify files created by somebody else.
surprisingly, some well-respected internet applications depend on being world-writable: http://www.wikipedia.org , for instance.
Vorn
"The end result of this is that anybody can create files and folders"
That’s correct, but therein lies the security hole…
Say a user has advance knowledge that a privileged process (e.g. an installer run by an administrator) is going to create and access a particular folder under All UsersApplication Data. That user could pre-create the folder using his account. He will then able to delete any files in the folder — including those owned by other users — and re-create them with malicious contents if he so desires.
Yes but the same thing can happen when installing for example to the root of a drive. So All UsersApplication Data is not particularly special in this regard.
If you’re installing something outside of %programfiles% then I think it is the installer’s responsibility to check for things like this. For example it could fail if the directory exists and is owned by somebody other than BUILTINAdministrators or current user.
Dustin,
As far as I remember, disabling "Simple File Sharing" enables the security settings dialog for the *shares* but does not provide access to the filesystem-level permissions.
Since the filesystem permissions trump the share permissions, and the share permissions only apply when accessing the share anyway, that’s useful only for adding stronger rules, not for relaxing security.
Given that it’s always possible to relax security at the system level, usually by either giving users higher system priviledges or by adjusting permissions on particular directories and files, I don’t mind that Windows allows me to make this *not* work. If I was developing a quick tool in a hurry I could just allow all users to write to the file in question, assuming I didn’t care about security. I could also pick a subset of all users who could write to the file, so that only those users who are trusted can access it.
Additionally, the newsgroup poster that Raymond linked to could make use of the registry permissions in Windows NT to achieve his end while still retaining the ability to restrict access at the user level.
In all situations where you could argue that relaxed security would make life easier, that relaxed security is available so long as you have the rights to enable it, and it’s granular enough that you have more options than just "All users can do x". If you don’t have the rights to enable it, then tough! :)
To clarify, "Application Data" and few other folders *under* All Users can be written to by Users, not All Users itself.
On a clean install of XP, cacls "C:Documents and SettingsAll UsersApplication Data" yields:
NT AUTHORITYSYSTEM:(OI)(CI)F
BUILTINAdministrators:(OI)(CI)F
CREATOR OWNER:(OI)(CI)(IO)F
BUILTINPower Users:(OI)(CI)C
BUILTINUsers:(OI)(CI)R
BUILTINUsers:(CI)(special access:)
FILE_WRITE_DATA
FILE_APPEND_DATA
FILE_WRITE_EA
FILE_WRITE_ATTRIBUTES
Curiously, the Microsoft subdirectory of Application Data has a different set of permissions defined on it that do NOT grant Users any write access. So the permissions we see here are only applicable to non-Microsoft programs.
Junction points are not like symlinks because they have TRULY SHITTY deletion semantics.
Delete a symlink, bye bye symlink.
Delete a junction point, bye bye data.
Wikipedia is almost world writable.
We have firewalled certain IP addresses and certain content across all projects (unruly crawlers mainly) and many more IPs are blocked on a per-project basis for content/ behavior reasons. We also block untrusted accounts from changing certain pages in certain ways. World writable is a handy tool but it does have its challenges, particularly with 250,000 changes per week, 20% of them from people with no account.
The last I’d heard, Ward Cunningham, known for creating the wiki concept, was a Microsoft employee now.
I’m one of the root admins on the Wikimedia/ Wikipedia servers. Figures for 7 days preceding this post, English language encyclopedia only.
Wikipedia uses a mechanism much like the "service" approach that Raymond described. Random users aren’t allowed to go and party on the data files; instead, they must go through a defined protocol interface which decides what they are allowed to do.
Wikipedia won’t let me go in and corrupt the database, and as James Day said certain pages can’t be changed by certain people.
As for deleting junction points, I think the problem is that the application-level tools aren’t aware of the junction point in the filesystem underneath. When Windows Explorer deletes a directory, it doesn’t just make an unlink (or equivilent) call on that directory because it knows it can’t delete non-empty directores that way, so it automatically recurses inside and deletes the contents.
This problem doesn’t occur on UNIX because the applications know about symlinks, and the rm and rmdir commands just make one syscall to remove that one item, unless of course you specify "rm -r", but then it can tell the difference between a directory symlink and a plain old directory.
I’m not sure if there are any calls that can be made on Windows to discover if a particular directory is a junction point, but if there are then Explorer should be extended to make such calls before deleting.
However, there are lots of other braindead apps which just blindly drill down through directory junctions; I have much of my second partition junctioned into places on my first partition (I’m a UNIX boi and I don’t much like having my data separated by an arbitrary distinction like what partition they are on. Sorry!) and there are plenty of apps which will just blindly recurse over the entire filesystem and then go ahead and do it again when they visit the other partition. Unfortunately, Windows comes with the heritage of having a really simple filesystem, so application programmers aren’t used to thinking about these kinds of issues. This isn’t really something that can be easily fixed, which is probably why there is no "easy" way to make a directory junction point.
Re: for the junctions and the ill beaving explorer: have a look at the shell extension "NTFS Link" on http://www.elsdoerfer.net/ which handles deletion and copying through a copyhook handler.
Re: for the world-writeable files Microsoft creates beneath %AllUsersProfile%: since NT RAS uses a world-writeable file RASPHONE.PBK to store connection data for dialup.
The phone numbers go there too, making it the ideal place for dialers to implant themselves!
I’d expect that about 10 years with NT should suffice to close this hole!
Giving people a file to use as a dropbox is probably a bad idea. Giving them a directory, though, should be OK if the permissions on the directory are set so they can create new files but not deleet or modify other people’s files.
"Armed with this information, perhaps now you can answer this question posted to comp.os.ms-windows.programmer a few months ago." perhaps not. the question is specifically about a common area in the registry. i don’t know what kind of quotas you can set on registry entries, but in any case i imagine that it’s a whole set of different problems than for the file system.
certainly the answer shouldn’t be "why the hell do you want to share data between users? what is wrong with you, don’t you know anything about security?"
the real answer is: "hi. here at microsoft we’ve managed to come up with the most labyrinthine morass of apis and specs ever. we can’t possibly start from scratch and "do it right" the first time. so when there is a question like yours, we choose the option that provides the most profit for the least amount of effort. in your case our answer is: ‘these are not the features you are looking for.’ you are wrong for wanting them. please buy one of our many microsoft press paperweights to determine what you should do instead. (and hope that you find the right book and that what you find works on most of the win32 variations that exist, which it probably doesn’t.)"
no offense to Raymond who’s obviously doing his best, which is pretty damned good.
You can do it, but world-writable files is not a secure way of doing it. I already described one secure solution in the article itself. Sometimes I wonder whether people actually read my articles before commenting on them…
Sorry for violating the 2-week limit Raymond, but I feel I have to respond! I did (and do) read your articles before commenting. I just don’t take very seriously the idea of running a custom-developed service (at an elevated privilege) just to share data between users of a single app.
Seems like overkill for the kind of app he seems to be thinking of. Maybe he’d be better off with RegSetKeySecurity?
Is it overkill not to want your app to show up in bugtraq as a security hole? "The XYZ program allows unprivileged users to corrupt the database and crash the administrator account."
It’s not overkill to do everything you can to avoid that bugtraq posting, no. You’re right. It just seems that a service is a ‘heavy-weight’ solution and not a good one. Getting a service running correctly (in a more privileged context, remember) is not necessarily the best solution. Indeed I suggested that I wouldn’t even take it seriously – I should qualify that: I would look for another solution in 95% of the cases where the issue arose. He wants to have a shared world-writable registry key. Instead of a service and all the complications it would bring (and extra resources it would consume – inside *and* outside of the computer!) … er …
Anyways – I’m getting past myself. I stupidly couched my point in "Microsoft FrustrationTM" on a Microsoft forum. The point is that this is such a common requirement that there should be a clear common way to do it! People who want to share application data securely between users on the same computer shouldn’t have to roll their own services!
That’s all. Sorry for being rude.
Another thought experiment when thinking through a feature.