It rather involved being on the other side of this airtight hatchway: Elevation to administrator


Surprisingly, it is not a security vulnerability that administrators can add other users to the Administrators group. But that doesn’t stop people from claiming that it is.

For example, it’s not uncommon for a vulnerability report to come in with the following steps:

  1. (a) Install this rogue service/driver, or (b) copy this rogue program to your machine and change this registry key in HKEY_LOCAL_MACHINE to point to it, or (c) replace this file in the system directory with a rogue program.
  2. Log on as an unprivileged user.
  3. Perform magical operation X.
  4. Boom! User is now an administrator!

Wow, this looks bad. An unprivileged user can elevate to administrator and… wait a second, what’s that in step 1?

To perform step 1, you need to have administrative privileges already. Only administrators can install services and drivers, only administrators can change registry keys in HKEY_LOCAL_MACHINE, and only administrators have write permission in the system directory. Therefore, this “vulnerability” basically says “If you can gain administrator privileges, then you can add anybody to the Administrators group.” Well, sure, but you really chose the complicated way of doing it. Once you get administrator privileges, just do a NET LOCALGROUP Administrators Fred /ADD and you’re done.

After all, why write a service or a driver when a batch file does the trick just as easily?

An alternative step 4 is “Boom! User is pwnz0red!” Well, yeah, an administrator can install software that commandeers user accounts. This is hardly a surprise, is it?

In a sense, this is “security vulnerability by obscurity”: By making your alleged exploit unnecessarily complicated, you can fool people into thinking that you’re actually onto something.

Comments (38)
  1. BA says:

    I think the "other side" posts are my favorite. They always poke holes in these silly little "exploits" that have fundamental logical problems.

  2. Tad says:

    One of my CSCI classes required me to read a book on a robot that committed murder. It was a small red book, that I can’t for the life of me, remember the name of. It had the greatest paragraph on security by obscurity, and now I can’t find it anywhere…

  3. BH says:

    @Tad: Was it perhaps Tik-Tok, by John Sladek? Although, the copy I have has a yellow cover. A particularly interesting and funny book. I’ll have to dig it out and see if I can find the paragraph you mean.

  4. Aaron says:

    Jack: Pray tell, what is this "major flaw in the security models"?  Common sense dictates that an administrator should be able to, you know, administer stuff.

    Figures that this rot comes from McAfee.  I’m still on the fence as to whether or not these security "researchers" are a net asset or a net liability to the industry.

  5. Lukas Beeler says:

    Previous Versions in Vista is restricted to Vista Business and up – so the only consumer OS that has it is Vista Ultimate.

    I would be interested why this decision was made, but i guess we’ll never know.

  6. Simon says:

    Home users can use Previous Versions, too. (I’m not sure exactly what versions of Vista you need, but it’s there.) -Raymond

    Only Business, Enterprise, and Ultimate have it; Home Basic and Home Premium don’t.  The two Home editions also lack the Complete PC Backup feature.  The latter especially is a puzzling choice, IMO — but that’s a discussion for another day; I don’t want to get too off-topic.

  7. Jonathan says:

    Aaron: I think Jack’s point was that administrators should somehow be protected from having programs that they run (at administrative privileges) unexpectedly perform administrative operations like adding users to the administrator group.

    Unfortunately that kind of protection seems pretty much impossible.  (At least without making the OS stop and make you prove [in some manner a rogue add can’t get around] that you are the authorized administrator and you did intend to perform that function.  Which would be so intrusive and annoying that it would pretty much cripple the OS)

  8. Suraj Barkale says:

    Thanks for the handy command line. I thought NET command was just for mapping drives. It seems to be the most powerful command on windows :)

  9. Scott says:

    It’s easy to find security holes.  I just found a new one, where I can post content to a Microsoft web server.  This is a serious hole since users may interpret this content as an official Microsoft position. :P

  10. Puckdropper says:

    Scott,

    It’s not a security hole if you’re allowed to do it by the administrator’s policy!

  11. Ulric says:

    You can’t protect the user from deleting his own documents "with a batch file". If you can ‘trick him’ into running a batch file with his own permission, then can you could trick him in doing any other things as well, for example running an executable that is using file sytem calls to do any amount of damage, or prompt him for password.  Strawman argument.

  12. Bryan says:

    I found a horrible security issue.  Apparently, on Vista, you can right-click on any shortcut or application and select "Run as Administrator".  If you had an Admin’s login/password, you could install a virus or trojan unwittingly.

    </sarcasm>

  13. Matt Brown says:

    This is how some people had gotten and continue to keep their jobs. :)

  14. Grant says:

    "I’m looking forward to Apple’s supposedly easy-to-use file history feature which should alleviate this problem. (Windows has one, also, if your files are stored on an Active Directory share, but that doesn’t help home users.)"

    (At least some) Vista users are protected by something similar at home:

    http://blogs.msdn.com/larryosterman/archive/2007/01/23/how-the-magic-of-windows-vista-saved-38g-of-my-data.aspx

  15. zahical says:

    A little bit late, but let me add my favorite "exploit":

    Windows allows you to start a console window under the SYSTEM account!

    Just type AT [hh:mm] /interactive cmd.exe (hh:mm is some time in the near future) at the command prompt and at hh:mm o’clock  a new command prompt will appear in which you can do whatever you want.

    There’s only one gotcha: To use ‘at’, you must be a member of the local Administrators group. :-)

  16. Cody says:

    [If you can trick someone into running a batch file]

    Your point being?  Tricking someone into running something means there’s a security flaw in either your policy or people, not programs.

  17. Jonathan: Up to a point, you could achieve some of this

    with capabilities: rather than having an all-powerful

    Administrator user, you have a list of things each

    process is allowed to do, so your backup program can

    access everyone’s files but not change user accounts,

    the time sync utility can adjust the system clock but

    not touch user’s files, etc.

    Ever heard of SELinux? No? That’s because it sucks. It’s unusable. No one can define a set of policies that actually works.

  18. Mikkin says:

    "Well, yeah, an administrator can install

    software that commandeers user accounts.

    This is hardly a surprise, is it?"

    It’s not, but it should be.

    Agreed. This is not something Windows addresses in this context, but in a secure environment letting an administrator impersonate or hijack a user account is a Very Bad Thing(TM). It rather involves there being two sides to the airtight hatchway.

  19. Jack says:

    "Well, yeah, an administrator can install software that commandeers user accounts. This is hardly a surprise, is it?"

    It’s not, but it should be. It points out a major flaw in the security models used by Windows (and Unix). Microsoft has tried to patch it up with UAC, but it’s basically just dumping the problem on the user (especially since UAC doesn’t give you the information you’d need to make an informed choice *even if you knew (and cared) what the application was trying to do*).

  20. James Schend says:

    Jack: At the risk of changing the topic too far from the original, I think the real problem with current security models is that you don’t *need* to be an administrator to delete the user’s most valuable data: Their documents.

    If you can trick someone into running a batch file, you can destroy thousands of dollars/man-hours worth of work in seconds without requiring any kind of privilege-escalation whatsoever.

    Sure, you can argue that this isn’t much of a problem because users back-up their data, the reality is that very very few users actually back-up their data. I’m looking forward to Apple’s supposedly easy-to-use file history feature which should alleviate this problem. (Windows has one, also, if your files are stored on an Active Directory share, but that doesn’t help home users.)

    [Um, home users can use Previous Versions, too. (I’m not sure exactly what versions of Vista you need, but it’s there.) -Raymond]
  21. James Schend says:

    Hm, I apologize then. I guess it’s a case of discoverability: I have a copy of Vista Home Premium that I’ve been using a few months now, and I haven’t seen any hint of any sort of Previous Versions feature. To boot, it’s not listed in the Product Features for any of the Vista editions. (Even Ultimate: http://www.microsoft.com/windows/products/windowsvista/editions/choose.mspx)

    That said, the Vista website kind of sucks. :) Before I bought this computer, I wanted to answer the question, "can I use my Home Premium  as both a Remote Desktop client *and* server?" and it’s nowhere to be found on the features page. (Nor does it mention whether applications like Cisco VPN will run on Home Premium, but I wouldn’t really expect MS to anyway.)

    Sorry for getting off-track.

  22. Igor says:

    Handy joke for Raymond:

    Your computer just got a "Bosnian Virus". Since we from Bosnia don’t have any programming experience, this virus works by exploiting your trust.

    Please delete all your files from your hard drive and manually forward this virus to everyone in your address book.

    Thank you for your cooperation.

    P.S.

    First forward the virus, then delete the files.

    :)

  23. KenW says:

    Jonathan: "I think Jack’s point was that administrators should somehow be protected from having programs that they run (at administrative privileges) unexpectedly perform administrative operations like adding users to the administrator group."

    So how do you protect "admins from programs that they run (at administrative privileges) unexpectedly perform administrative operations"? How do you know the administrative operation is unexpected? Perhaps it’s doing exactly what the administrative user expects, so it’s not unexpected. Perhaps it’s doing something the administrative user doesn’t, which means it’s unexpected. How do you, the operating system, tell the difference? How do you know if the user expects the behavior or not? Read the user’s mind? Not gonna happen (and if it did, someone would sue). Ask the user? Oh, yeah. That’s what UAC does already, and people are complaining about that all over the place.

    The solution to security issues is simple, both on Windows and Linux:

    Don’t run as administrator/root unless absolutely necessary, and then for only as long as you must.

    Use the lowest level of access you can on your normal (non-admin) account, to keep processes run as that user from causing problems.

    Don’t install stuff into the Systems folders without knowing what it is and where it came from.

    Leave UAC turned on on Vista.

    Use AV software and a firewall.

    I’m still on XP, both at home and work (my home laptop is only about a year and a half old, and doesn’t quite have the juice for Vista; at work, we *just* got rid of the last Win98 machine about a month ago, and still have about half XP/half Win2K on our 50+ workstations). I follow the advice above (except UAC being turned on, which of course doesn’t apply). In 20+ years of using PCs, with various versions of DOS and Windows, I’ve been affected by only a single virus, and never had spyware infect my machines.

  24. James says:

    Jonathan: Up to a point, you could achieve some of this with capabilities: rather than having an all-powerful Administrator user, you have a list of things each process is allowed to do, so your backup program can access everyone’s files but not change user accounts, the time sync utility can adjust the system clock but not touch user’s files, etc. The Windows NT kernel actually has a fair bit of this implemented behind the scenes, even though the obvious aspects are basically limited to Administrator/Backup Operators/Users.

    One thing to be careful of is that as soon as an access control list is wrongly configured, step one of Raymond’s list becomes possible *without* already being Administrator. Mark Russinovich had some articles about this on his blog last year and again this year; Power Users (pre-Vista) are also able to elevate themselves to Administrator status with just a default Windows system, and ordinary Users can do so with a lot of third-party software with poorly written ACLs.

    In Raymond’s examples, ‘*install* this rogue service’ requires Administrator privileges – but ‘*substitute* your own rogue file for this legitimate one which runs privileged’ often doesn’t. Particularly on non-NTFS systems of course!

  25. Cheong says:

    [quote user="Ramesh Dharan"]

    Ever heard of SELinux? No? That’s because it sucks. It’s unusable. No one can define a set of policies that actually works.

    [/quote]

    No. Actually "no one can define a set of [b]predefined[/b] policies that actually works".

    It CAN work, just that requires tremendous effort of fine tuning. And of course, the administrator’s knowledge of how to get SELinux work.

  26. DriverDude says:

    In the context of the linked article, this "security report" seems quite absurd.

    But do not underestimate how easy step 1 is.

    Look for the paper "Windows Access Control Demystified" (1st hit on Google and Live Search, wow!)  It details how Windows XP allows a regular user to change the executable of a Local System service (this bug has been patched)

    I was so shocked that a market-leading PhotoEdit package could allow normal users to change its files that I actually installed it. Indeed, the installer changes the ACL on all its files so Everyone can write to all of them. Think about it: instead of inheriting ACLs from C:Program Files, the installer changed the ACL on each file one by one.

    This isn’t some obscure app written for Win95. This is a whole suite of apps produced by an A-list Silicon Valley sofware company, costs $700+, released in 2005 and "designed for XP". They also released an update after the bug was found.

    Just because these bugs have been fixed (and an admin user shouldn’t be editing photos), does anyone seriously think there aren’t more of these bugs on the average system?

  27. dewd says:

    I created a backdoor on my linux box today, here’s how I did it:

    Put this in /etc/xinetd.d/backdoor:

    service backdoor

    {

     type = UNLISTED

     socket_type = stream

     protocol = tcp

     wait = no

     user = root

     port = 2456

     server = /bin/bash

     server_args = -i

    }

    Then save (:wq in vim), and restart xinetd. Then when you connect to that box on port 2456, *Boom!* you got a root shell!

    (Why did I do this? I wanted to see the symlinks in /proc/self/fd while running from xinetd, the quick&dirty way)

  28. Stephen Jones says:

    —-"It’s not, but it should be. It points out a major flaw in the security models used by Windows (and Unix). "—–

    So it’s a security flaw that people who own systems can do things to them? It’s that goddam  subversive free-will. If people and computer users, would just act like robots within the instructions they’ve been given all will be solved.

  29. Name required says:

    Use the lowest level of access you can on your normal (non-admin) account

    Good advice, but easier said than done. Too much software requires admin rights to install (good, in many ways) and also admin rights to run (for example because the software tries to write to an "admin only" directory when it is run).

    My favourite exploits requires you to have physical access to the machine. And a hammer.

  30. Jules says:

    One good one that happened to me.  A while back, I was involved with an open source development tool.  Somebody posted a security bulletin to a number of popular security web sites that there was a remotely exploitable security fault in our tool: if you set up a system where it compiled any program that was e-mailed to a particular account you could exploit a buffer overflow and run code with that account’s priveleges.

    Nobody ever explained why you’d compile code in an account that was more priveleged than you intended to run the compiled program in, or why it was better to include the exploit code in binary in an overly long identifier rather than as source in the program that was being compiled.

  31. Triangle says:

    “Only administrators can install services and drivers”

    So unprivileged users can’t just attach their devices to Windows and have it automatically install them? Something that isn’t a security issue conceivable way ?

    [You already know the answer to this; you just posted the comment to show off. Don’t make me bring back the nitpicker’s corner. -Raymond]
  32. James Schend says:

    > You can’t protect the user from deleting his own documents "with a batch file". If you can

    > ‘trick him’ into running a batch file with his own permission, then can you could trick him in

    > doing any other things as well, for example running an executable that is using file sytem

    > calls to do any amount of damage, or prompt him for password.  Strawman argument.

    Maybe it’s a "strawman" argument, I don’t really know. Think about it from a usability perspective for the average user though.

    The fact is that right now "security" in the computer world means two things:

    1) A user can’t mess with the OS

    2) A user can’t mess with another user’s settings/files

    Those are fine goals (especially the second one), but neither help if you accidentally type "del *.*" in a terminal window.

    Most of the people here are programmers. We’ve seen technology (source control) that can keep track of every change to a file, roll back to any point in history, even keep track of deleted files and bring them back if necessary. Why isn’t this a *standard* feature in every OS for every file? It’s a complete no-brainer.

    Say there’s no tricking involved, say you just made a simple mistake, drag the wrong file. Office apps have Undo, why shouldn’t the entire OS? You should always be able to restore older versions of a file, or bring a file back from being deleted (whether it was deleted with file system calls or by being thrown in the trash) as long as HD space allows. And for most users now (the ones who basically just surf the web and maybe use iTunes or a digicam), HD space will allow a LOT of history.

    The things the security model protects now, the OS and programs in the Program Files folder, cost nothing but time– a user can re-install them from the CD in a couple hours. But the files in their personal documents could be invaluable. All these security features are totally bass-ackwards, if you ask me. They should protect the most valuable data first, and the re-installable stuff second.

    You’re also ignoring that once a user runs a program, they have no way to know what that program is actually doing. Sure I’m giving HappyScreenSaver permission to run, but when I do that, I have no clue that it’s going to wipe My Documents, and the OS sure as hell won’t tell me.

    End rant, sorry.

  33. Triangle says:

    I don’t know the answer, as I haven’t tried yet on any Vista PCs. Also I wasn’t trying to show off, since a blog isn’t the appropriate place for that. But apparently I shouldn’t have. So I apologize.

    Please don’t bring back the nitpickers corner.

    [Obviously, the administrators approved the installation of drivers that come with Windows when they installed Windows. -Raymond]
  34. Michiel says:

    I do keep wondering why a user is allowed to call CM_Request_Device_Eject but not send IOCTL_STORAGE_EJECT_MEDIA.

    (Both can be used to unmount USB Mass Storage devices, the device itself isn’t informed in the latter case.)

  35. nksingh says:

    @Michiel:

    Not 100% sure about this, but if two users were using the USB drive on the same machine, the second IOCTL could cause another user to lose data, which would be unacceptable.  The earlier one may not suffer from this risk.

  36. Myria says:

    This is the same reason that mandatory driver signing is absurd for any reason but DRM.  If you can install a kernel driver, the system is already taken over.

    It’s really a protection against fake sound card drivers, not rootkits as claimed in Microsoft marketspeak.

  37. @Myria

    Obviously the assumption is that if a driver is signed, it has been reviewed and is stable and secure. As long as this assumption is true, then it doesn’t matter what signed driver you install; you won’t be able to use it to install an unsigned driver, because that’s a security hole (were you planning on writing a driver, magically loading it without getting it signed, then using it as a back door to load unsigned drivers like you said?). More generally, the entire system will be more secure and stable if you cannot load unsigned drivers (again dependant on that assumption being true).

    I’ll leave debate of the assumption itself to others.

  38. Miral says:

    I hang around installer forums a fair amount, and the standard assumption on most people’s part when coming in seems to be "I want to store my data files in the application folder.  Vista (or XP-LUA) doesn’t let me do that.  So how do I change the file permissions to let me?"

    The thing is, no matter how many times you tell people not to do that, they keep coming.

    (The other common one is "I want my normal users to be able to upgrade this program from a web download, without having to elevate".  Cue loud screaming noises from the security-conscious.)

Comments are closed.