FAQ: Why can’t I bypass the UAC prompt?

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 make the "standard user" the default for Windows, encouraging software developers to create applications that do not require admin. It's not perfect by any means, but changing the ecosystem will take a long time, 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
  June 30, 2007
  If privilege elevation was really required, as opposed to lazy programming, wouldn't the classic approach be to delegate the privileged operations to a device driver or a system service?I.e. SQL server requires special privileges to access the data files, but end users don't need any special admin rights to connect to the database.

• Anonymous
  June 30, 2007
  "Unix and Unix-like OSes such as Mac OS X" ... did  typing Linux hurted :)

• Anonymous
  June 30, 2007
  Since RunAs.exe won't run a program elevated, is there a way to trigger an elevation prompt from a script?

• Anonymous
  July 01, 2007
  The comment has been removed

• Anonymous
  July 02, 2007
  The comment has been removed

• Anonymous
  July 18, 2007
  Great article.I was hoping that explanation like this would be published by Microsoft along with release of Vista.There have been too many questions like: "why just does not Vista copy Unix/Mac security?" and part of your article is good answer to that question.

• Anonymous
  August 09, 2007
  One thing that I hear echoed is why isn't there a set way for a program to detect at what level it's running instead of just "try and fail". That doesn't seem as well designed as if you have an api way to know if you can or can't do something -vs- let's try something catch the failure or force a admin dialog when we could be smart and not do it to being with.Thoughts?

• Anonymous
  August 18, 2007
  What about COM+? Isn't it easy to configure any COM-object to run evelated? [Aaron Margosis]  Out-of-process COM objects can be configured to run elevated, but you still get a UAC prompt before it occurs.

• Anonymous
  August 20, 2007
  The comment has been removed

• Anonymous
  September 17, 2007
  The important point missed in this feature is UI experience. After a while user habitually clicks on yes, making this whole exercise fruitless. [Aaron Margosis]  I don't think so.  What you've called out is a potential problem, but what we're expecting is that after a system has already been set up and apps have been installed, users will see few if any prompts, so each one should stand out and command attention.  I think the UI experience is actually not bad at all -- it's better than training users to reflexively type their passwords, as other systems do. :-)

• Anonymous
  October 18, 2007
  While I understand where Microsoft is coming from as far as needing to break the cycle, everyone I have talked to about Vista immediately says, "turn off UAC and it will solve most of your problems." If everyone turns off UAC because it is so troublesome and there is no way for admins to make it do what they want, then the whole UAC exercise is pointless. There NEEDS to be a way for admins to configure programs to run with admin rights without giving the users admin credentials. At the end of the day, if UAC hinders business, UAC will be disabled. If it takes 3 lifetimes to figure out how to make UAC do what you want, UAC will be disabled. While it may sound like a responsible moral decision, Microsoft is no further ahead by trying to force this issue.

• Anonymous
  October 19, 2007
  I totally agree with Karl's post..."turn off UAC and it will solve most of your problems."  It will.  I am having a terrible time transitioning our scripts, programs, software, and policy to the UAC environment.  I want to use the UAC, but it is going cause so much in-efficiency in our system, i don't know how we are going to do it.  It think the UAC works well at home, but in our large enterprise, it is not working well with automated tasks.

• Anonymous
  October 19, 2007
  By the way, someone want to try testing something?  I think this is a problem related to the UAC.  I'll give you my test scenario.Windows Vista Enterprise 32-bitJoined to domainGPO that runs a batch file that maps a drive (net use)Put a domain group in Administrators, put a different group in UsersLog on the machine with a domain account in the Users group.  You should get your mappings.Now put a group (can be same group as in Users) in the Network Configuration Operators group. Now log on again with the domain user account.  Did you get your drive mappings?  I don't.If I turn off the UAC then I do get the mappings.  If I take the group  back out of Network Configuration Operators, i get mappings.  For giggles, instead of adding the group to NCO I tried Power Users, and again no drive mappings.  Take the group out and drive mappings are back.  But the problem is not just the drive mappings, other programs do not work right in this scenario.

• Anonymous
  August 31, 2008
  The comment has been removed

• Anonymous
  August 11, 2009
  Here's my problem. Users don't have admin rights. App requires elevation - I can't change that, it is what it is. So whenever the user runs that app they have to come to me to type the admin password for them. Either that, or I give the user the admin password, in which case I might as well make them an admin. Now, doesn't THAT defeat the ENTIRE purpose of users no longer running as admins? [Aaron Margosis]  The idea is that apps to be run by users shouldn't require admin rights in the first place.  Apps should require admin rights only if they are performing legitimate administrative operations.  Can the vendor (or internal developer) update the app so that it works correctly as standard user?  If not, there are many mitigations that can help get these apps to work correctly without admin rights.  (Which one to use depends on what it's doing that fails, or why it's demanding UAC elevation.)

• Anonymous
  January 18, 2010
  The Symantec link has changed - that blog post is now at: http://www.symantec.com/connect/blogs/danger-speling-mistakes [Aaron Margosis]  Fixed.  Thanks.

• Anonymous
  September 10, 2010
  I'm using task scheduler to start applications autoelevated since Vista Beta2 and this works fine. So I can put a schtask shortcut in startup folder and they run elevated without any interaction.

• Anonymous
  September 07, 2011
  if wscript.arguments.named.exists("elevated") = false then  createobject("Shell.Application").ShellExecute "wscript.exe", """" & wscript.scriptfullname & """ / elevated", "", "runas", 1else  'what you want to do with elevated rightsend if

• Anonymous
  April 09, 2014
  Vista is proved to be a bad release for MS, as is Win 8. A bad product does not necessarily mean every aspect of the product is bad, but quite a few are indeed bad. IMHO, UAC feature is bad when manipulated/presented in such a way by MS, yet, the bad decision maker(s) never get deserved consequence.

• Anonymous
  June 18, 2015
  The comment has been removed