FAQ: Why can’t I bypass the UAC prompt?
[This item was authored by Aaron Margosis and originally appeared on his Non-Admin Blog .]
The frequently asked question, "Why can't I bypass the UAC prompt?" is often accompanied by statements like one or more of the following:
- "We want our application to run elevated automatically without prompting the user."
- "I don't get why I can't authorize an application ONCE and be done with it."
- "Unix has setuid root which lets you run privileged programs securely."
The designers of Windows Vista's User Account Control expressly decided not to incorporate functionality like setuid/suid or sudo found in Unix and Unix-like OSes such as Mac OS X. I think they made the right decision.
As I'm sure everyone knows, large parts of the Windows ecosystem have a long legacy of assuming that the end user has administrative permissions, and consequently a lot of programs work correctly only when run that way. (I'm not going to delve into that history here, nor will I entertain any finger-pointing on the topic at this time. One of these days I'll post my thoughts on that subject.) As computer security has become increasingly important, breaking that cycle became absolutely imperative. It is with the release of Windows Vista that the first major move in that direction is achieved. Indeed, the primary purpose of the technologies that comprise UAC is to enable "standard user" to be the default for Windows, encouraging software developers to create applications that do not require admin. The move to standard user is a new paradigm and creates the need for software developers to write applications that do not require admin privileges. Creating a shift in the ecosystem will take a long time due to the large deployed base of legacy applications, and UAC is a good first step.
Pre-approving code to run with elevated permissions without going through an elevation prompt, as described in the bulleted scenarios above, seems at first glance to be both useful and convenient. However, the negatives far outweigh those benefits. In particular:
- The "standard user by default" vision would become impossible and ultimately never happen;
- Elevation of privilege (EoP) would be trivial – any compromise could lead to full system compromise.
If it were possible to mark an application to run with silently-elevated privileges, what would become of all those apps out there with LUA bugs? Answer: they'd all be marked to silently elevate. How would future software for Windows be written? Answer: To silently elevate. Nobody would actually fix their apps, and end-user applications will continue to require and run with full administrative permissions unnecessarily.
What if the application could not mark itself for silent elevation but instead had to be marked by the consumer or enterprise administrator installing the application? Answer: the developer of the installation program (which necessarily runs with admin/system permissions in order to install machine-wide) would figure out where the setting lived, and set it. (Several major ISVs told us directly that they would in fact do exactly that.) There would be no real way to protect that setting from anything running as admin. This would be especially true if it were settable via Group Policy (which would be expected, if not demanded).
"Well, so what? We're only talking about applications I approved!" OK, let's say that's true, but how do you ensure that a malicious user cannot use the application for purposes other than those for which it was intended? And at least as important – how do you ensure that malware that has infected the user's session cannot drive a setuid application programmatically to take over the system? Ensuring strict behavioral boundaries for complex software running with elevated privileges is (at best) incredibly difficult. And ensuring that it is free of exploitable design and implementation bugs is far beyond the capabilities of software engineering today. The complexity and risk compounds when you consider how many apps have extensibility points that load code that you or your IT admin may not be aware of, or that can load code or consume data from user-writable areas with minimal if any validation.
Privilege escalation due to setuid and sudo has plagued Unix-like systems for many years, and continues to do so. In fact, several of the bugs in the recent Month of Apple Bugs fell into this category. Follow these links for lots more references: (*)
- Secunia items re SETUID and local privilege escalation
- Secunia items re SUID and local privilege escalation
- MOAB posts involving privilege escalation
- Symantec write-up on how easy it is to subvert sudo
- Ease of exploiting a sudo authn "grace period"
In the past, elevation of privilege has tended not to be noticed in Windows – there is no real "elevation" if you're already running as admin. (**) With the Vista shift toward "standard user", EoP threats become much more important, and it is vital that Windows do as much as practical to mitigate them. That is also why Windows services are no longer able to interact with the user desktop. Taking on the setuid headaches that *nix has had to live with does not seem like a profitable deal.
We expect that in ordinary day-to-day usage, users should rarely, if ever, see elevation prompts, since most should rarely, if ever, have to perform administrative tasks – and never in a well-managed enterprise. Elevation prompts are to be expected when setting up a new system or installing new software. Beyond that, they should be infrequent enough that they catch your attention when they occur, and not simply trigger a reflexive approval response. This will increasingly be the case as more software conforms to least-privilege norms, and as improvements in the Windows user experience reduces prompting further.
Having said all that, there is a Local Security Policy option to change the behavior of the elevation prompt for Administrators to "elevate without prompting". With this option selected, anything that requests elevation gets elevated without prompting the user. (The default setting is "prompt for consent"; the third option is "prompt for credentials". Note that "elevate without prompting" is available only for members of the Administrators group. The options for standard users are "prompt for credentials" and "automatically deny elevation requests".) While "elevate without prompting" may be useful in well-constrained, secure environments for automated testing and possibly for initial system setup, having this option selected otherwise is very risky and strongly discouraged. (Note also that Vista's Home SKUs do not include the policy editor.)
Nitpicker's corner (***)
(*) Pointing out the obvious: local privilege escalation by definition means that the bad actor is already on your system. However, there's a huge difference between malware running as you (non-admin) and malware running with root privileges. If there weren't, there would be no point (from a security point of view) in running with least privilege.
(**) "Elevation of privilege" in this context means "unauthorized elevation of privilege". Technically, yes, Administrator is not as powerful as System (in that there are operations that Administrator will get Access Denied where System will succeed), and System is not as powerful as kernel-mode code (in that there are operations that fail for user-mode code running as System that succeed when called from kernel code). However, two of the things that Administrator is authorized to do include: 1) configuring arbitrary code to run as System, and running it; and 2) loading arbitrary code into the kernel, and running it. Hence, if code is running as admin, there is nothing it is not authorized to do.
(***) "Nitpicker's corner" might be a trademark of The Old New Thing.
Comments
Anonymous
August 09, 2007
That's a very good and interesting summary. Personally I think a lot of the Unix vs Windows issues here are cultural. For example, in the Unix world it's common for an app to create and install its own user (which may or may not be less privileged than root :-), which makes finer-grained control easier. With Windows apps, and we're talking third party apps mainly rather than Microsoft's own, services almost universally run as SYSTEM or similar. There's often no reason why they can't run as a dedicated user and/or at lower privileges, but the de facto standard (probably as its the easiest option) is to run admin. I personally think it's good that you've taken a strong stand on UAC; I suspect that after a year or so of bickering the development community will catch up and everyone will benefit from least privilege by default.Anonymous
August 10, 2007
The comment has been removedAnonymous
August 10, 2007
That is the best justification for the way UAC currently operates that I have seen so far. This may cause some inconvenience in the immediate future, but ideally newer software will work better with it. I do thing there are some things that could be addressed with its current implementation. Some operations seem to require far too many prompts. For example copying a file into a system directory first comes up with a prompt saying it will require administrative privileges, and then followed by the UAC prompt. This would be better wrapped into a single prompt. Before reading this article I also would have advocated having an option to allow a program to always be elevated. However I would instead settle for a feature that allowed me to temporarily disable UAC prompting (without rebooting) while I performed some system maintenance. While in every day usage the UAC prompt should not appear often, there are times where a lot of configuration is required (for example setting up new programs). I do find it tedious to have to click through many prompts. I am guilty of using a workaround when I am going to be doing several administrative tasks. I bring up a command prompt with elevated privileges, terminate explorer, and reload explorer from the command prompt. Now explorer is elevated and anything that it launches will also be elevated. When I have finished I terminate explorer again and reload it from a non elevated prompt. This is quicker than disabling UAC, rebooting, then re-enabling and rebooting. I would be interested to see if Microsoft would be willing to implement a temporary suppression of the prompt. This would be a non persistent setting that only lasted until the user reset it or computer rebooted. Additionally it could potentially be set on a timer. For example, suppress UAC prompting for next 30 minutes. Ben. [Aaron Margosis] What kinds of tasks are you performing that having Explorer elevated helps? (If it's unavoidable, you might want to review this post.) Suppressing prompting for a period of time runs into the same problems described above.Anonymous
August 10, 2007
The comment has been removedAnonymous
August 10, 2007
so the user can only use code that has been allowed to run? who decides what can run if not the user?Anonymous
August 12, 2007
The comment has been removedAnonymous
August 13, 2007
The comment has been removedAnonymous
August 14, 2007
The comment has been removedAnonymous
August 14, 2007
The comment has been removedAnonymous
August 15, 2007
The comment has been removedAnonymous
August 15, 2007
http://blogs.msdn.com/windowsvistasecurity/archive/2007/08/09/faq-why-can-t-i-bypass-the-uac-prompt.aspxAnonymous
August 15, 2007
http://blogs.msdn.com/windowsvistasecurity/archive/2007/08/09/faq-why-can-t-i-bypass-the-uac-prompt.aspxAnonymous
August 28, 2007
The comment has been removedAnonymous
August 28, 2007
The comment has been removedAnonymous
August 29, 2007
The idea of prompting an administrator everytime he needs to do something is ludicrous. If I'm logged in as administrator, I should have the keys to the kingdom. If I'm not competent to make decisions about which programs I run and what processes I perform, then I shouldn't be logging in with administrator privilege. Please give me the freedom to shoot myself in the foot on my own computer if that's what I want to do. [Aaron Margosis] If it is your computer, you already have the freedom to shoot yourself in any way you want. You can set the elevation prompt behavior to "elevate silently". You can disable UAC completely. You can reset access control in the registry, file system, DCOM launch permissions, etc., to grant Everyone "Full Control". Godspeed. But we're not going to make that the default for everyone else, OK?Anonymous
August 30, 2007
As an IT guy, I absolutely agree with Steve above. If I want to shoot myself...let me! It is my responsibility to secure my systems against viruses, spyware, spam, etc. with the best tools possible. This issue and others have kept us from upgrading to Windows Vista...we remain at Windows XP Pro and Windows 2003 Enterprise Server. Microsoft, if you want to do me a favor, have your security capabilities configurable by the administrator. That is, allow the admin user to install "trusted software" without the prompt. The admin can supply a list of "trusted" software apps that don't require the UAC prompt. If the app is not trusted (yet), allow an option to make it trusted from here on out. [Aaron Margosis] Dave, my apologies if I sound flip, but did you read the post? In a perfect world where software (and software engineers) truly possess magical powers, what you're asking for would be great. But as detailed in the post, it would ultimately harm customers/users more than it would help them.Anonymous
October 01, 2007
Quote: But as detailed in the post, it would ultimately harm customers/users more than it would help them. Not as much as having to turn off user access control entirely just to run an application as administrator without typing in a password every time. Much as I applaud your efforts to avoid security pitfalls, if the alternative to a user unfriendly nagging prompt is no security whatsoever, then people will settle down with no security and we end up exactly where we began.Anonymous
October 01, 2007
The comment has been removedAnonymous
October 12, 2007
The comment has been removedAnonymous
October 19, 2007
Hi Aaron, In response to your question about what tasks I need explorer elevated, the answer turned out that I didn't need explorer elevated. I just used it as a convieneint way to launch other apps that are now elevated. The times I want to be able to have UAC temporarily suspended is when I want to perform a lot of admin tasks in a row. For example installing a bunch of apps. I have found a happy solution though since I first read this article. I now have a registry file that sets "auto consent" on. This does exactly what I wanted. I only have to answer the prompt once for that and then I can perform all other tasks with elevation occuring automatically. When I am done I set the setting back. While I will agree that having this temporary auto elevate on does expose the system somewhat. It is a risk I am willing to take. And while I have the computer in this state I am not running my web browser etc. Ben.Anonymous
December 24, 2007
The comment has been removedAnonymous
January 29, 2008
Try to download an EXE from the web. How many warnings do you see saying that what you download could be malicious? (including the yellow bar at the top of IE6 SP2)How many of those warnings are people so used to seeing that they simply respond "yeah yeah whatever - click"? Now add a new warning at every new generation of the OS and/or browser. How long before it becomes a "yeah yeah whatever - click" ? I'm not saying UAC is a bad idea. I like it. I feel it protects my system, however rarely it may come up. It's not my system I'm worried about, it's my 70-year old dad's.Anonymous
February 03, 2008
Implementation of security in any OS is the responsibility of the user. Microsoft, governments etc. seem to believe that their role is to interfere where I believe it is to carry out the wishes of the group. I would advise a look at the history of past totalitarian regimes, all have failed, as will Microsoft if they do not produce an OS for adults. I will now load W2K on my brand new laptop.Anonymous
February 08, 2008
I am a software engineer facing a strange thing. Our software works just fine with UAC off as an admin or limited user. Turn it on and it doesn't work, admin or limited doesn't seem to matter. But the worse issue is this. If it is on during the install, even if you explicitly elevate the installer, the install fails, and wedges itself so that even uninstall and reinstall with UAC off fixes it. Therefore I have been asked for a programatic way to disable UAC that will stick without reboots. The problem is not admin vs. limited at all. UAC itself is the problem. [Aaron Margosis] That sounds very unusual -- have you gone in with a debugger to identify the specific failure points? Feel free to contact me directly through the contact link on my own blog,Anonymous
February 13, 2008
I am writing as an end user, a gamer, rather than a security person. UAC prompts way too much. I agree with CS, it's incredibly annoying. If a user want to lower security allowing a program to run again that still has the same checksum I think that would be a good compromise, but only if the user uses the extra checkbox for that. What happens now is that users get fed up with the constant nagging from UAC, and disables it. Example: at one time I had two applications that wanted to elevate at boot:last.fm and xfire. I have password on for UAC as well. So writing passwords three times at bootup got me extremely fed up with UAC. I really felt the Mac Ad was right on the dot. Now last.fm introduced an extra service in order to avoid elevation every bootup. Xfire guys refuses to do that, so if I didn't change the config for some games (in fact disabling xfire support for those games) I would still get an UAC prompt every boot. <rant mode="on"> Now the extra service makes me think of startup programs which I really hate. I don't need the machine to boot up any slower, it boots really slow now, since every developer seem intent on sticking an extra process in startup. </rant>Anonymous
March 22, 2008
There are something i can not download that i know are safe. How do i bypass this security to download.Anonymous
April 04, 2008
I for one run as a limited user on both XP and Vista. I like UAC. The one problem I see is that to elevate requries knowning another (administrator) account's password. If I know this password, then there is nothing preventing me from just logging in as this administrator to begin with (at least on Home versions). What I have done then to protect my admin account (at home at least) which should virtually never be used for anything is to create a new group called "Superusers" (only an admin can add users to it) and a service called "Superuser Manager" - when the service sees a member of Superusers group (like my limited user self) log on, the service adds me to the administrator group (so, now I am in both Users and Administrators groups). So, desktop explorer is running as a limited user and when I run something that requires evelated rights, UAC prompts and behold my user self is in the list and I can enter my OWN password to elevate the program. When the "superuser" logs off, they are removed from the Administrators group so the logon/logoff process can be repeated. This whole thing works on XP as well and 2000 (not with service though) and you can Runas to elevate essentially. The only thing I wish I could do is "hide" the real admin user from the UAC dialog completely... There seems to be no way of having administrator accounts that never show in the UAC list...Anonymous
April 06, 2008
TweakUAC (http://www.tweakuac.com) Runs on Home/Home Premium, removes the @#$% repeated escalation prompts. The alternative is disable UAC completely, which defeats the purpose.Anonymous
April 14, 2008
By not providing setuid capability, you have forced us back into using administrator accounts. I've got a custom h/w + s/w solution that requires admin privs to run. I'd like to setup a non-admin user account, and give admin privs to the custom app only. Since that is not possible, the only solution is to use an administrators account. [Aaron Margosis] Another option: figure out why the app requires admin rights and address that problem. Is the purpose of the app to do computer administration? If not, then the app shouldn't require admin rights.Anonymous
April 14, 2008
[[Aaron Margosis] Another option: figure out why the app requires admin rights and address that problem. Is the purpose of the app to do computer administration? If not, then the app shouldn't require admin rights.] One of the apps is a control panel applet, which accesses a device driver via an ioctl interface and writes to the registry. Should this require admin rights?Anonymous
April 14, 2008
Does that type of object have an ACL? If so, the device driver ought to specify whether a user is able to open it. Writing to the registry is a question of where, and what.Anonymous
April 17, 2008
The comment has been removedAnonymous
June 16, 2008
The comment has been removedAnonymous
June 16, 2008
I wanted to add, We had a couple of vendors tell us they weren't going to recode for Vista, and to either run as a local admin with UAC off or don't use thier software. We aren't using thier software.Anonymous
July 02, 2008
The comment has been removedAnonymous
July 23, 2008
The comment has been removedAnonymous
July 23, 2008
The comment has been removedAnonymous
July 24, 2008
The comment has been removedAnonymous
September 04, 2008
hello I have a problem using Windows Vista since the last update of program gives me this error when trying to connect to a server (Xfire requires UAC elevation to run the game) someone knows how I fix am from spain and I use a translator to write I hope that I understand. thanksAnonymous
September 24, 2008
The comment has been removedAnonymous
October 29, 2008
[Aaron Margosis] If malware has been able to run at system/root level, you have no assurances that you'll be able to detect the infection, let alone remove it. The integrity of the trusted computing base (TCB) has been compromised at this point, so no information you receive from it can be trusted. Well hidden malware can also often find ways to hide even when you boot into a separate trusted OS (e.g., from a CD) -- that's assuming the BIOS itself hasn't been 0wn3d. BTW, this isn't just a Windows issue -- the same is true of Apple, the *nixes, OS/2, etc. One of the big reasons for running as non-admin is to protect the integrity of the OS.