Este conteúdo não está disponível em seu idioma, mas aqui está a versão em inglês.
Esta documentação foi arquivada e não está sendo atualizada.
Security Watch The Long-Term Impact of User Account Control
Dr. Jesper M. Johansson is a Principal Security Engineer working on software security issues and is a contributing editor to TechNet Magazine. Jesper holds a Ph.D in MIS and he has more than 20 years of experience in computer security.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.
Dr. Jesper M. Johansson
The problem with running as an administrator is obvious: any malware that attacks users, or the applications they run, will have full control over 90 percent of the computers it infects. The User Account Control (UAC) feature in Windows Vista is the Microsoft solution to a pervasive security challenge—the fact that over
90 percent of users currently on the Windows platform run with administrative privileges. While it is possible to run as a standard user on Windows® XP—and I have—it can be extremely painful. For instance, if you travel frequently while using Windows XP, you'll find that as a standard user, you're unable to modify the time zone on your system.
UAC is the feature that is supposed to change all that. Actually, that's the first misconception. UAC is not just a feature; it is a collection of features, most of which are not particularly obvious. I won't give you an in-depth analysis of all the implementation details of UAC. For that, I highly recommend Mark Russinovich's article in the June 2007 issue of TechNet Magazine, which you can find online at technetmagazine.com/issues/2007/06/UAC.
Rather, in this piece I hope to give you an unbiased view of what UAC is, what it is not, and how that affects the way you should manage your systems that are running Windows Vista®.
What UAC Appears to Be
The most visible feature of UAC is the elevation dialog, shown in Figure 1. In fact, if you were to ask a representative sampling of Windows Vista users what UAC is, the majority would likely say something about the annoying elevation dialog.
Figure 1 UAC approval dialog for administrator in admin-approval mode (Click the image for a larger view)
In spite of the visibility and all the opinions about UAC, I do not believe that most of the discussion about UAC has very much to do with what UAC really is. In fact, there seems to be some real confusion out there. Pundits write blog posts, newsgroup entries, and articles with titles like "Vista's Most Annoying Feature," and they pontificate on how many people will turn it off and why it is so annoying.
Given that so few have bothered to understand the rationale behind UAC, why don't I start this column with a look at what UAC is?
What UAC Is
UAC is an attempt to enable more people to run as standard users. In a sense, it is version 2.0 of that effort. Version 1.0 shipped first in Windows NT® 3.1 and enabled a user to run as a non-administrator. This was a radical departure from the 16-bit Windows 3.1 and its successors, Windows 3.11, Windows 95, Windows 98, and Windows Me, none of which had any concept of low-privileged users. Whether a non-administrator could actually do anything useful depended on a lot of factors, but up through Windows XP and Windows Server® 2003, least user privilege often ranged from painful to useless. Windows Vista brings the first set of technologies aimed at making it easier to do the right thing when it comes to interactive user privileges.
While it is correct to claim that a goal of UAC was to provide some level of protection for apps running as an admin from those that were not, that was not by any means the primary purpose of UAC. The primary purpose was to start us on a path where more users run as standard user, which in turn would force developers to write more programs that work as a standard user, reducing the number of situations where users need to elevate. As developers write more UAC-compliant apps, the number of prompts the user gets goes down and the user experience gets better. In the process, ideally we end up in a situation where most people do not run as administrators and, hopefully, they start questioning some of the elevation prompts they do get. The fewer the prompts, the more likely users are to consider them carefully before allowing them.
Or so the theory goes. By extension, yes, there may be less malware, but that will depend on whether users keep UAC enabled, which depends on whether developers write software that works with it and that users stop viewing prompts as fast-clicking exercises and actually consider whether an elevation request is legitimate.
To meet the major goal of increasing the number of users who can run as a non-administrator most of the time, UAC is designed to meet a number of constituent goals:
- Decrease the number of scenarios that require elevation to an administrative account.
- Make elevation considerably easier—automatic if possible—than the previous kludges such as using runas.exe or logging out of one account and into another. In other words, bridge the gap until ISVs fix their applications.
- Provide some isolation for those applications running as an administrator to protect them from those that are not.
- Enable certain exposed applications to run with even lower privileges whenever possible.
Two of those goals aim to make the user experience of running as a non-admin as palatable as possible. Two have to do with protecting applications that are particularly exposed.
What is interesting is that only two of them are related to the feature that is popularly seen as UAC, and only one deals with the actual elevation task. Yet the elevation, when an application asks for additional privileges, is what people complain about because it is the only really visible manifestation of the collection of technologies that comprise UAC. The first overarching goal has nothing to do with elevation at all. The idea was simply to enable more people to run as non-admins most of the time. In fact, you could argue that the intention is to reduce the number of elevation events.
The goals related to the elevation task itself are goals 2 and 3. Goal number 2 is about making elevation easier than it was in Windows XP, and goal number 3 is about providing some level of protection for applications that are running elevated. The remaining goals have to do with entirely different issues. Each of these goals required changes to the operating system, however. Mark Russinovich's aforementioned article details these changes for those that are interested.
As I mentioned, there are many, many recommendations out there to disable UAC. It is likely that a number of users will do so without even trying it, and many more will get their computers from some big-box store, complete with a Windows Vista build that has UAC disabled already. I think it's shameful that retailers are disabling important security features in the operating system as part of their default deployment image.
Unfortunately, much of the advice to turn off UAC is based on the initial experience. While setting up your computer, you get a fair number of prompts as you install software and make any necessary changes. You should expect that you will have a very different administrative experience while you are configuring your computer than you will once the computer is in a steady state. The first few weeks will be quite different from the following few weeks. If you try UAC on a computer that is in relative steady-state, I think you'll find that it is really not particularly intrusive at all.
What UAC Is Not
UAC was not deliberately designed to be the most annoying feature in the history of Windows. Rather, this set of technologies was designed to set us on a path where users do not need to expose their systems to potentially malicious code as frequently as they have during the past few years.
In its current form, UAC will not stop really good attackers, or ones who have the help of really good attackers. If the bad guys can't think of any other way to defeat UAC, they will almost certainly resort to asking the user to do it for them. Given the choice of dancing pigs and security, we know from experience that the dancing pigs win every time. Users have learned to dismiss dialogs, and so they will until we manage to teach them otherwise. This results from many contributing factors, including the fact that there are too many warning dialogs, that the messages in them are useless, and that many of the manuals for whatever devices users buy include a note to "please click yes to the security warning dialog to dismiss it."
UAC does not provide foolproof security. In fact, it makes the good old local privilege elevation attack interesting again. This is a class of attack that has largely been discounted because, on Windows, nearly everyone was an admin anyway so elevating to some other admin was quite pointless. That said, UAC definitely changes the nature of such attacks and transforms the rules of the game to be much more like what prevailed on UNIX for more than 20 years.
UAC will not stop bad guys from stealing your personal data. A user's personal data is accessible to that user regardless of the user's privilege. As such, an application, including a malicious one, can access the data. UAC does not, and cannot, change that. It does not eliminate the need to be vigilant, distrustful, and paranoid—attributes we should all instill in our end users at every opportunity.
UAC was not designed to protect an application running with elevated privileges from all attacks by an application that runs with normal privileges in the same login session. While UAC does provide some weak process isolation, it was not a design goal for UAC to sandbox applications from each other.
Microsoft itself contributed to both the buzz about UAC and to the misunderstandings about what it does. In the Windows Vista Security Guide, for example, the "Defend Against Malware" chapter presents UAC as the primary technology that does so (microsoft.com /technet/windowsvista/security/guide.mspx). It recommends running with UAC turned on—for the most part—and it lists a number of points to consider when using UAC to combat malware. One point, however, is glaringly missing: UAC does not, nor is it intended to, stop malware.
Some of the brightest thinkers in the world on Windows security today, such as Joanna Rutkowska, did understand UAC's purpose. As she put it in a blog post on February 4, 2007, UAC "is a new security mechanism introduced in Vista, whose primary goal is to force users to work using restricted accounts, instead working as administrators" (theinvisiblethings.blogspot.com/2007/02/running-vista-every-day.html). She has it mostly right, except I would use the term "enable" rather than "force."
This, however, means a significant change in the nature of common attacks against Windows. As I mentioned earlier in this column, local privilege escalation vulnerabilities, where a user can escalate from a local standard user to a local administrator, have never been particularly interesting on the Windows platform.
With Windows Vista, the idea is that users will run as standard user instead, and suddenly local privilege escalation issues become very interesting. Unfortunately, this is also where we run into some of the limitations of UAC. Remember, there is no effective isolation; there is no security boundary that isolates processes on the same desktop. The OS does include some protective measures to keep the obvious and unnecessary avenues of communication blocked, but it would be impossible and undesirable to block them all. Therefore, Microsoft does not consider breaches of that nonexistent security boundary to be security breaches. Mark Russinovich pointed out as much in a blog post at blogs.technet.com/markrussinovich/archive/2007/02/12/638372.aspx.
Mark is totally correct. Microsoft is well aware of the fact that there is no security boundary between a low process and an elevated one on the same desktop. As there was never intended to be any isolation between processes on the same desktop, it really can't be called a security vulnerability when it is discovered that there is no isolation between processes on the same desktop. Obviously, that diminishes the value of UAC as a first-order mechanism for fighting malware, but it was not designed to be that anyway, despite what you might read in various places, including some from Microsoft.
Does this fact diminish the value of UAC with regard to its primary goal—enabling more people to run as standard user more of the time? No. The existence or lack of an impervious security boundary between a malicious low-privileged app and an elevated application does not change the fact that more users can effectively use UAC and run their Windows Vista computers as a standard user. In fact, contrary to what some in the industry would have you believe, I wrote this article (and my entire book on Windows Vista Security for that matter) as a standard user on Windows Vista, and not once did I get a UAC prompt asking me to accept anything that I wrote!
The fact that UAC does not mitigate all security problems, or that it does not possess a property that many of us, myself included, would dearly like to have—first-order protection against malware—does not mean it is not a security technology. The ability to identify users through separate user accounts does not, by itself, stop malware from infecting your system, but nobody would stretch that fact into meaning that user accounts, therefore, are not a security technology. That UAC does not solve all the problems we would like it to solve for us does not mean that the problems it does solve are not valuable.
UAC leaves it up to technologies such as the vastly improved Windows Firewall, Windows Defender, and other anti-malware programs to keep malicious code off your box and to keep it from executing if it gets there anyway (whether due to wily programming or flying pigs). None of those security technologies is likely to be 100 percent successful at their missions either, yet they are all valuable security technologies and all have their place. But, as I have said many times before, even if all avenues of attack are shut down, it all comes down to the user. If the person at the keyboard chooses to allow malicious code to run, no technical mitigation in the world will help.
How should you use UAC? Should you run as an administrator in admin approval mode? As noted several times, UAC does not prevent code injection from a lower privileged application into a more privileged application on the same desktop. This means that neither running in admin approval mode nor as a standard user and elevating within session (over-the-shoulder elevation) provides effective isolation. However, either solution is far better than running as an administrator under Windows XP or with UAC turned off in Windows Vista. Eventually, however, malware will probably be written to take advantage of elevated applications on the interactive desktop.
How you decide to run, then, depends on your risk management philosophy. When you run as a standard user and use over-the-shoulder elevation to elevate an application, the elevated application has a different user environment than the regular ones. This lessens the risk of a poisoning attack, where a malicious non-elevated application poisons the user environment for an elevated one, but it does not necessarily remove the ability of a non-elevated application to control an elevated one. While a malicious application that ran weeks ago cannot easily poison an elevated application you run today, a malicious application running now may be able to control an elevated application. You need to consider the risk tradeoff of using admin approval mode or over-the-shoulder elevation in context of the ease of use it provides.
This leads to a set of best practices for UAC, summed up in Figure 2. The best option by far, in my opinion, is also the most complicated. However, for the truly paranoid or exposed, the best option is to run as a standard user and never elevate. In a sense, running as an administrator under Windows XP, once you ran malicious code it was game over. Under Windows Vista, if you run malicious code and then elevate within that session, it is likely game over. You are free to pick whichever approach works best for you and provides a level of protection you are comfortable with.
|Protection Level||Elevation Method|
|Worse||Turn off UAC.|
|Bad||Automatically elevate administrators.|
|Good||Run in admin-approval mode.|
|Better||Run as standard user and elevate to a separate admin account.|
|Best||Run as standard user and switch user to a separate admin account instead of using UAC to elevate.|
In addition, the truly paranoid do not trust the vendor when it says its app must run as an administrator! One of the most visible examples of where this claim is made but is not true is Visual Studio® 2005 Service Pack 1. When you launch Visual Studio, you are told you should run it as an administrator. However, this is only true for developers who need to perform certain tasks. More information is available at msdn2.microsoft.com/en-us/vstudio/aa972193.aspx.
Empower the User
Users should be empowered to make more and better decisions. There is a contingent of security professionals who believes security decisions should be hidden from the user. Their unspoken rationale is that users are not only uninterested in security, they are not intelligent enough to learn how to do it properly. Only by relying on Insert-YourFavoriteAntiTechnologyHere will they be properly protected.
I fail to see how technology can ultimately protect people from attacks targeting people. The majority of attacks today, including virtually all phishing attacks, are targeted primarily at people and how they run their computers, not at the technology inside those computers. The most effective of these attacks may blend attacks on people with attacks on technology, but they still often require user interaction to run. Technology simply cannot be expected to protect against attacks that are not targeting technology. I wrote a lot about that a while ago: technetmagazine.com/issues/2006/07/SecurityWatch.
UAC is already forcing users to make security decisions, and there are already promises from technology vendors for solutions that prevent users from making those decisions. It is true that users prefer not to be bothered by security. However, it is also true that no software can discern intent in other software. No intrusion prevention system can tell whether a Web site is asking for your credit card number so it can ship you a copy of Windows Vista Security or so that it can send it off to a shadowy criminal organization. Only the end user can do that and only if proper information is given. As software engineers we need to accustom users to the fact that they need to make intelligent security decisions, teach them how, and give them the information they need to do it.
If we persist on our current path—of attempting to prevent users from making security decisions—we will only find that we are unable to protect them. Users will eventually tire of getting hacked and having their privacy, bank accounts, identity, dignity, and self-respect violated. When that happens, they will stop using the products we need them to buy to sustain the industry. There are those in the high-tech industry who believe that if we withhold the fact that there are security issues with computers and e-everything, users will blindly use whatever we throw at them. Nothing could be further from the truth. When users finally realize that we have not been open and honest with them, they will lose faith and trust entirely and turn away from our products, causing a collapse of the very industry we are trying to protect by withholding the facts.
UAC is an exciting step in the direction of empowering users to take responsibility for the security of their systems. It is by no means a complete security solution but, as a first attempt at helping users run with least privilege, it is definitely a significant step in the right direction.