eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
A controversy erupted last week with the revelation by a researcher that it is possible for a user-mode program in Windows 7 to disable User Access Control in the default configuration. My first reaction to this was that it was bad, but it’s a beta and it will be fixed. Now I’m getting the vibe from Microsoft that it won’t be fixed and I can see their argument. It still leaves me uncomfortable, though.
For those of you unfamiliar with the specific problem, in Windows 7 the default behavior of UAC was changed so that the user is not prompted for access to Windows programs, such as control panel applets, as they are in Vista. UAC also no longer uses the “secure desktop” mode for confirmation by default.
And a new control panel is provided to let the user choose the behavior of UAC in Windows 7. There is a slider control with 4 levels: level 4 is the same as Vista, with all the same prompting for system-level changes and secure desktop; level 3, the default, is the same as level 4, but doesn’t prompt for changes in Windows settings, like the control panel; level 2 is the same as level 3, but does not use the secure desktop; and level 1 shuts off UAC; no prompting at all. The secure desktop is a special mode in which you can only interact with the UAC prompt, and no other software.
The proof of concept showed a user-mode program which spoofed keystrokes and mouse movements to change the setting from the default down to level 1.
What bothered me was that this was user-mode code. It seemed to me that it sort-of violated at least the spirit of UAC by indirectly elevating privilege through an external program, which level 3 is supposed to prompt. The author of the attack proposed what seemed a sensible solution: force a prompt, one that requires secure desktop, for that one case. The heart of the argument for making this a special case is that users would expect from level 3 that it would protect them from elevation changes from external programs.
There was a lot of hyperbole about this issue. There are many legitimate arguments that this isn’t so bad a problem, and in fact not surprising at all. Some of them are made in Roger’s Security Blog, who closes with the point that a lot of the criticism is hypocritical, amounting to calls for more rigid prompting from people who complained about it in Vista..
The more I’ve thought about it, the more I think Microsoft is right not to make a change here. Here are the major arguments for this position.
You have to run an untrustworthy external program for the attack to work. The fact that the attack can be a VBScript is of no importance. It’s generally understood that once you run some arbitrary program on your computer you are putting yourself at risk. So the attack gets a foot in the door through the user’s fault, not Windows’.
Attack Works Only as Administrator
The attack only works when the user is logged in as administrator. Log in to Windows 7 as a standard user and try this; from the default setting you can change the slider to “Always prompt,” the Vista equivalent, but to make the setting less strict you have to be logged in as administrator. Thus the user lets the attack have another foot in the door by ignoring another important security feature of Windows.
And in fact, almost the whole point of UAC is to let users run as standard users. And if you want to run as Administrator and be protected from this attack, change the UAC setting to Always prompt, as with Vista. It’s true that the default user account after an installation is administrator, but Microsoft does encourage users to create and use standard user accounts. And in an enterprise it would be criminal incompetence to let normal users run their desktops as administrator. (But even if you do, there are group policies to control UAC that override user settings.)
UAC is not a security boundary, as Microsoft’s Mark Russinovich explained to some confusion in this TechNet Magazine article. A real boundary, like an ACL, for instance, sets actual rules based on policy. UAC is a convenience for the user; it doesn’t stop you from running certain programs, it just tells you what they are and gives you the option of not running them. In fact, there are probably many other ways around UAC, and securing them would be a game of whack-a-mole. Microsoft will probably decide not to whack this particular mole, lest it create a precedent that they must whack all the others. This doesn’t help anyone.
The technique could be used for far worse things. Control panel has many important system-wide settings in it. You can set user passwords, uninstall software, disable the firewall, and so on. All of this is possible because of the default UAC setting, and you don’t have to change that setting to “exploit” it.
The more I think about this problem the less impressed I am with it. It solves little for Microsoft to change the behavior of this one applet and users who are actually concerned about it have plenty of ways to protect themselves. What this episode demonstrates more than anything else is that security is complicated and not every problem is worth solving.
Thanks to Cameron Sturdevant of eWEEK Labs for helping me confirm some of the points in this article.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
For insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer’s blog Cheap Hack