There are really only two effectively distinct settings for the UAC slider


There's a control panel that lets you specify how often you want to be prompted by UAC. You can set any of four levels:

  • Always notify
  • Notify only when apps try to change settings, use the secure desktop
  • Notify only when apps try to change settings, don't use the secure desktop
  • Never notify

Although it looks like there are four settings, in a theoretical sense, there really are only two settings.

  • Always notify
  • Meh

The reason why all the other options collapse into Meh is that the Notify only when apps try to change settings option can be subverted by any app simply by injecting a thread into Explorer and doing its dirty work there. Since Explorer is a program that the setting allows to elevate silently, this lets you perform a silent elevation from any thread that has thread injection rights into Explorer (which is pretty much any program running at medium integrity level or higher).

In other words, Notify only when apps try to change settings is really Punch a hole in the airtight hatchway.

If the intermediate settings are effectively equivalent to Never notify, then why are they there in the first place?

Because people wanted them.

UAC in Windows Vista had only two settings: Always notify (enabled, default) and Never notify (disabled), because those are the only two meaningful values. But people complained as loudly as they could that the Always notify level of prompting was far too annoying.¹ As a concession, Windows 7 introduced two intermediate levels of prompting, even though the two new levels are effectively equivalent to Never notify because the notification can be bypassed by a program that puts it mind to it.

As Larry Osterman noted, UAC is not a security feature. It's a convenience feature that acts as a forcing function to get software developers to get their act together.

I remember back in 2009, there was a lot of hubbub over a "security hole" in the UAC control panel because it let you change the UAC settings without prompting, if the old setting was Notify only when apps try to change settings.

Well duh.

You configured UAC so that it prompts only if an app is changing a system setting, and not if the control panel itself is changing the setting. You then use the control panel to change a system setting. Therefore, there is no prompt.

Still, enough people complained that they wanted more prompting that the UAC folks added an extra prompt. "I thought people complained that there was too much prompting, and then when they set the slider so it prompts less, they demand more prompting? Can these people make up their minds already?"

¹ Personally, it doesn't bother me. It's not like I spend my day constantly changing system settings. In fact, I keep my account out of the administrators group, so not only do I get prompted for everything, but when I do elevate to administrator, I'm running as the local administrator account, not as myself. This means that the elevated command prompt does not have domain network access (because domain access came from my domain account), and the domain account does not have administrator access.² This "separation of powers" helps limit the scope of any dumb mistakes I may make, since a rogue command running as administrator cannot access network resources, so any runaway command is limited to screwing up only my own machine.

² It's surprising how many programs stop working when faced with this dichotomy.

Comments (65)
  1. parkrrrr says:

    "It's surprising how many programs stop working when faced with this dichotomy."

    Somehow, I don't think you're as surprised as you let on.

  2. skSdnW says:

    There are more levels than this if you edit the registry. My personal preference is Always notify, don't use the secure desktop.

    1. Rick C says:

      Can't other applications drive the UAC prompt if you're not using Secure Desktop? If that's the case, there's no real point in having the prompts at all.

      1. skSdnW says:

        Yes it is theoretically less secure. Consent runs at system integrity level but there might still be shatter attacks that could work and the secure desktop would protect you from that. For ultimate protection you must run as non-admin and enable the Ctrl+Alt+Delete requirement policy so nobody can spoof the UAC dialog where you have to enter a password...

  3. Koro says:

    Is this post related to the "fileless UAC bypass" that was posted a few days ago? (https://enigma0x3.net/2016/08/15/fileless-uac-bypass-using-eventvwr-exe-and-registry-hijacking/)

    1. That's rather unlikely ... Raymond's posts are queued days/weeks/months before they go live.

      JFTR: mitigation for this UAC bypass is simple:
      [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
      "C:\Windows\System32\EventVwr.Exe"="RunAsInvoker"
      ;"C:\Windows\SysWoW64\EventVwr.Exe"="RunAsInvoker" ; on 64-bit systems only

  4. Joshua says:

    I'm glad that *someone* at MS is willing to admit this particular truth.

    I'm still waiting for a LOGON32_LOGON_INTERACTIVE_ELEVATED to appear so that I can make UAC go away when logging in from a context that can't elevate because it can't display a prompt. I can fake it LOGON32_LOGON_NETWORK_CLEARTEXT but this yields the wrong privilege check (can access files over the network != can run arbitrary programs).

  5. 'k says:

    I think you're being a bit disingenuous when you say "People wanted them". People simply didn't want the annoyance. In hindsight, MS somewhat avoided the PR backlash of moving to XP by (effectively) removing security completely to allow for an easier transition for W95 apps. It just came back to bite you guys in the ass, big-time.

    1. xcomcmdr says:

      Security was added to XP (I think mainly of the famous SP2), but it's the first time I hear that security was removed from XP at release. You have any source for your claims ?

  6. parkrrrr says:

    There's really only one setting anymore. On Windows 7, you could actually turn it off. On Windows 10, nope. It might appear that it's off, but just try launching an application that's manifested for high IL with NTSD.

    1. Yuhong Bao says:

      It may be more accurate to say that all other UAC settings makes UAC useless in terms of security. It still needs to be partially on in order to support Metro apps.

  7. Joshua says:

    As for the "more prompting" when turning UAC down; at this time two things were true; 1) people still believed it was a real security barrier at anything other than the highest setting (and now even this has been called into doubt) and 2) practical attacks involving injecting explorer hadn't been discovered yet. The cryptbase hole wasn't known.

  8. pb2004 says:

    Problem is UWP Settings app works correctly only on "Notify only when apps try to change settings, use the secure desktop ". On "Always notify" for example compare what you get when you click on your ethernet adapter in Network -> Ethernet section. Other example is Reset/Refresh system action and info about wrong uac level

  9. SatoMew says:

    Ever since Windows 7, I've set UAC to Always Notify. The PC Settings app in Windows 8 and 8.1 or the Settings app in Windows 10 either hide certain functionality or display an erroneous message that the feature is unusable due to how UAC is set despite being able to trigger the Consent UI anyway (an example of this is the option for resetting the PC in the Recovery section).

    Another behavior is that the app can trigger too many UAC prompts, like in the Region & language section, in which denying elevation will trigger the same prompt a few more times: https://i.imgur.com/a9tbm0U.png

    Raymond, are elevated apps supposed to not gain focus after granting them the privilege in the Consent UI? It happens here on Windows 10 and the secure desktop being enabled or disabled doesn't seem to have an effect on the behavior. I have to focus the app as its window is opened in the background instead of in the foreground. What's strange is that it doesn't always happen because sometimes the elevated app's window is opened in the foreground.

    You and Larry also mention that UAC is a convenience feature as opposed to a security feature. Well, isn't it both? After all, certain features like Internet Explorer's Protected Mode (sandbox) or file and registry virtualization don't work if UAC is disabled. There's also TechNet documentation that describes UAC as a "security component": https://technet.microsoft.com/en-us/library/cc507861.aspx

  10. Yuhong Bao says:

    Win8.x even has bugs that allow UAC bypass even with "Always Notify". And with "Always Notify" even Task Manager results in a UAC prompt.

    1. SatoMew says:

      Mind shedding some light on those bugs? And the new Task Manager requires elevation because it uses ETW but you can force it to run without admin privileges. In a command prompt window, run set __COMPAT_LAYER=RunAsInvoker, then taskmgr.

        1. Medinoc says:

          Damn, I thought at least always-notify UAC was supposed to work. But if Microsoft doesn't treat actual, always-notify UAC bypass vulnerabilities seriously, then UAC is COMPLETELY useless. Can I downgrade my "main" user account from Administrator to regular user relatively painlessly?

      1. Neil says:

        Oh wow! now I can actually run RegEdit et. al. as limited me. Thanks!

        1. You don't need to set the __COMPAT_LAYER environment variable to override the execution level specified in the application manifest.

          [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
          "C:\Windows\RegEdit.Exe"="RunAsInvoker"
          ;"C:\Windows\SysWoW64\RegEdit.Exe"="RunAsInvoker" ; on 64-bit systems only

          1. SatoMew says:

            Both methods have their uses. The environment variable doesn't have to be permanently set since you may only be testing things out. And the instructions you provide work for both 32-bit and 64-bit systems, you only have to use the executables in SysWOW64 if you need to specifically run the 32-bit version on 64-bit Windows.

  11. James says:

    If UAC was supposed to change developer behavior I definitely think Microsoft missed the memo. Many things are now optimized for the the default UAC level, such as the ridiculous fact that opening the Task Manager on Win8+ requires clicking through a UAC dialog. But that pales into comparison when trying to actually use a normal account with a separate admin account using over-the-shoulder elevation. I found things like EMET just not displaying its GUI if you elevate, to just yesterday when I got a UAC prompt during the "Hi" start animation after upgrading to Anniversary edition. You don't make it easy.

    1. Don't forget that there are many parts of Microsoft. Saying that one part of Microsoft missed the memo is not the same as saying that all of Microsoft missed the memo.

      1. Mormegil says:

        Yeah, while there are not that many “people”, so that “Can these people make up their minds already?”

    2. Joshua says:

      For extra fun, I bet *bad things* happen on pressing No to that particular prompt.

    3. SatoMew says:

      Speaking of EMET, the latest release is still not properly DPI-aware, which makes it look blurry at 150% scaling, for example. I guess it could have to do with its custom GUI but that then begs the question of why is a Microsoft app using one in the first place...

    4. Ben Voigt (Visual Studio and Development Technologies MVP with C++ focus) says:

      It's understandable that testers might be running signed executables in an environment with UAC set to defaults, and miss catching the excessive number of prompts that occur with strict UAC.

      What I have trouble understanding is how the developers miss this usability nightmare, when working with compile outputs that are unsigned (or test-signed). Do they have their test-signing certificates loaded into UAC on their own machines, so that they'll get the UAC experience matching "executables which will eventually be signed and trusted"? If so, are those development certificates globally trusted by UAC (very bad!) or installed on a per-machine basis? Does the build process during development generate RTM-signed executables (also very very bad)? If they are locally-trusted developer certificates, how can I load my own developer certificates into UAC on my computer?

      Or are those developers running with UAC totally disabled? I should think that in the interests of (a) dog-fooding and (b) protecting MS source code against corruption by malware, UAC would be mandated for MS development computers by policy (both corporate and Active Directory).

  12. Injection of a thread into Explorer is NOT necessary at all: there are quite some other executables which can be used instead of Explorer, and RunDll32.exe as well as RegSrv32.exe can load a DLL which then instanciates one of the about 100 COM objects for which auto-elevation is allowed.
    JFTR: WUSA.exe does this too, without the need for a DLL and the COM object.

  13. jon says:

    UAC was originally a security feature, and when Vista came out Microsoft promoted it as such.

    It was retrospectively downgraded to "not a security feature" in Windows 7, when Microsoft got cold feet because of the criticism over the number of prompts Explorer gave you for simple things (e.g. create a folder in C:\Program Files and rename it would prompt 3 times). Instead of fixing it properly, they waved the magic wand and hey presto, not a security feature any more therefore.

  14. @Joshua, I suspect you'll find that LOGON32_LOGON_BATCH meets your needs.

    1. Joshua says:

      Nope. LOGON32_LOGON_BATCH fails for most users that have permission to log in interactively, at least here.

      Explanation: LOGON32_LOGON_BATCH only succeeds for users who are allowed to schedule tasks.

  15. Raymond, this is @SwiftOnSecurity, and I run DecentSecurity.com. Thank you for putting this in such stark words in 2016. I try to tell people this, and having this link will make it so much easier.

  16. Ivan K says:

    One thing I've noticed is that, as a local non-administrator user, I can sometimes go to "Settings -> Apps and Features -> Manage optional features" and instantly hit a UAC prompt (and further prompts as I try to do stuff in that settings area), but other times no UAC prompt will show. I'm not sure what steps lead to the show vs. no-show scenario, except I know that in both cases I haven't accessed the "Settings" UI at all after login or computer restart before seeing/not seeing the prompt. My UAC setting is currently the default "Meh".

  17. Jason says:

    I honestly wish you guys would use UAC more, not less, especially with UWP apps. It is convenient as hell to go to a user's computer and not have to log out of the user's account to do system/admin work. Minimal disruption.

    You also need to find a way to allow running UWP apps as admins or different users. If, for example, Notepad ever becomes a UWP app under the current system, we will have a serious problem. I'm not logging out of my standard-user account just to edit a config file located in a privileged area. That's stupid.

  18. Ian says:

    Raymond, I might have misunderstood, but you imply that you work in the main without admin rights, or when you do upgrade to admin rights you lose access to shared drives that depend on your domain network access. I can't imagine being able to work this way as I've always assumed I need admin rights for full debugging and for installing services that I'm developing etc, as well as fiddling with Registry settings. (I know I can modify Registry security settings in particular keys, but this seems impractical, at least until things have settled down and I know what keys I'm working with.) What have I missed?

    1. Ben says:

      You can develop and debug e.g. web services without admin, by setting the appropriate ACL on the HTTP listener endpoint using netsh. You can debug a window service if you install it to run as yourself (or if you give it a standalone mode in which it can run without being installed as a service).
      If you need to attach a debugger to a service running as a privileged account, then yes, this is equivalent to having administrative privileges anyway.

    2. Voo says:

      The first thing I do when developing a service is to separate all the functionality into a separate dll and then run the code as a console application. There are ways to debug services otherwise but I find everything else way more hassle than it's worth it.

      Yes you still have to test the real service in your test environment and if you find bugs there you may have to debug the service locally but that should be exceedingly rare.

      For web services you can just set the ACL as Ben says (that's important also in production! Don't run your web services as admin user!)

      1. JDG says:

        You can make the same EXE act as either a console app or a service by simply deciding whether you are going to call StartServiceCtrlDispatcher or not (ServiceBase.Run in C#), e.g. based on the command-line. I usually set my services up to run as a service with /service and a console app with /console, and to select automatically if neither is specified based on whether a debugger is attached at startup.

        1. Ian says:

          This is in fact exactly what I do. For some reason I had got it into my head that special privileges are needed to attach a debugger (regardless of the process being attached to), and in my organisation you are either a locked down user or (provided all the necessary authorisations can be obtained) a local admin.

  19. cheong00 says:

    Just curious, is there any setting that blocks thread injection to Windows process that have "silent elevation" built-in? Since UAC is roughly about pulling "Built-in Administrators" and "Local account and members of Adminstrator group" right away, unless the user also have debugging right, I think something could be done to close the hole.

    Maybe it'd be easier to have policy that deny thread injection to DEP enabled processes?

    1. Chris says:

      I think that'd be fairly difficult to do under the current Windows security model. In general, the security boundary is the user, not the process. Users have full control over programs running with their identity. Even if you modify the ACL on the program to disallow injection/memory tampering, I think programs also running as the user, in the same session, could still modify it back.

      1. cheong00 says:

        I think they cannot add back explicitly denied roles without UAC elevation? If that's true, I think blocking some action based solely on whether current process identity with/without these roles is possible, just not sure if it's possible to block thread injection based on that.

    2. 1. Explorer(.exe) does NOT have "silent elevation" built-in!
      2. you can't inject a thread into an elevated process (running with high integrity) from an unelevated process (running with medium integrity).
      3. elevation does NOT occur in the midst of a running process, but only at process start.
      4. the IFileOperation COM object runs "out-of-process" (c.f. DLLSurrogate), the injected thread only loads a DLL which performs the call of this COM object.
      5. it's (not just) this COM object that is silently elevated when called from an executable signed by the "Windows Publisher".

      1. cheong00 says:

        1) See Raymond's explanation on "meh" part.
        2) Explorer.exe is never run elevated.
        3) You can restart a process with elevation (see ProcessExplorer and other utilities of the sort). And btw seems the MsiInstaller can request elevation consent in the middle when it's already executing, I think maybe that's also possible.
        https://blogs.msdn.microsoft.com/heaths/2007/07/12/immediate-custom-actions-always-impersonate/

        No comment for 4 and 5.

        1. You need to understand what "silent elevation" means in the context Raymond presented, and how it works.
          This is what 4) and 5) are all about.
          JFTR: "restart process" == "start process"

  20. fsociety says:

    Wrong in details: http://www.kernelmode.info/forum/viewtopic.php?f=11&t=3643&start=110#p29058
    Suggest to read the whole topic of the autoelevation "feature".

  21. MarcK4096 says:

    This is disappointing to learn, but informative. I always thought auto-elevation was only allowed for certain predefined actions. Thread injection would be trivial for a malware author to implement.

  22. MarcK4096 says:

    I just loaded up a Vista system and deleted a folder from C:\Program Files. Here are the prompts I got:
    Explorer: Do you want to move to recycle bin? - Clicked Yes
    Explorer: You need to confirm this operation. - Clicked Continue
    UAC Prompt - Clicked Continue

    I think it was those extra "you need to confirm this operation" prompts from Explorer that really fed the criticism.

    1. SatoMew says:

      This is still the case in Windows 10 if UAC is set to Always Notify and the Recycle Bin confirmation prompt is enabled, the latter which is disabled by default since Windows 8. Otherwise, you get two prompts using the default settings on Windows 7 or only one prompt using the default settings on Windows 8 and 10.

    2. Ben Voigt (Visual Studio and Development Technologies MVP with C++ focus) says:

      This strongly suggests that the Out-of-process-COM-call-using-elevation action ought to provide the application some input into the UAC prompt. Namely (1) Some additional explanation to be shown the user (2) A flag for "always require confirmation, even if UAC settings allow auto-elevation". Then explorer could use that for the confirmation, instead of an Explorer-generated confirmation followed by (maybe, depending on UAC level) a UAC elevation prompt.

      Of course, since we don't want to expose the secure desktop to shatter-attacks and buffer overflows in a rich text parser, this explanation should be very limited. My vote is for plain text with a maximum number of newlines (perhaps 6) and a maximum total number of bytes (perhaps 1000).

      That's plenty for an explanation of the operation (You are attempting to move/copy/delete files in an Operating System/access controlled folder), along with the target or source/destination file specifications. And flexible enough to be useful for things other than file operations.

      Note that this is not replacing the existing information on the UAC dialog, and needs to be presented as "The application provided the following message" so it is not confused with trustworthy information collected by the OS (since drive-by browser exploits will start using this for their "your computer is infected" fraud, you need to give users a chance to see that this message about a virus is coming from my web browser, not from my antivirus program)

      1. yukkuri says:

        Only if you volunteer to be the one that cleans up after all the users that fail to recognize the difference and trust it anyway.

      2. Erik F says:

        This, of course, assumes that users actually read messages. Having done helpdesk duty, I've lost confidence in people reading prompts (particularly when reading prompts written in programmerese, a close relative to Klingon.) Additionally, many prompts don't come from the program level but from the framework level, where prompts would be more generic by necessity and could easily be misleading for people who are not proficient in lower-level computer concepts. I'm not saying that having more helpful messages would be bad, but just that they would be perceived as noise to many users if the feature was used incorrectly.

    3. roeland says:

      This happens any time when you move files, and either the source or destination doesn't have write permissions for regular users. You’ll get a prompt that you’ll "have to provide administrator permission…”, followed by the actual UAC prompt. I wonder what’s the rationale behind that first dialog. No other application does this.

      This is still an improvement over Windows XP, where that move would require running a third-party file manager as Administrator.

  23. jgh says:

    Every time (ok, both times) I've taken my PC to the local repair shop, it's come back with my user account set to Admin "because it's convenient". No, it's dangerous. The reason that only Admin is allowed to do Admin stuff is to ensure that only Admin is allowed to do Admin stuff.

    But then, I was administering networked resources back in 1985 and my default mode of thinking is that users are users, not admins, non-user files only have user read permissions, etc.

  24. Mark says:

    Suppose there were a hypothetical 5th, option: always notify, use normal desktop. Would this be meh as well?

      1. Joshua says:

        This makes reference to something I had been intending to ask about. We know the UAC itself appears on the secure desktop by default; but the spawned privileged application does not. Without regards to UAC itself; the change of access levels of windows on the same desktop would make a good topic /and is relevant even if UAC is disabled/.

        Although I am left wondering if the UAC prompt is subject to attack if not on the secure desktop, than why bother attacking it; just wait for the next privileged GUI application and attack that. I always thought it was merely defending against a fake UAC box to steal passwords; which is not very meaningful if [Yes] [No] kind of UAC box.

  25. viila says:

    https://blogs.msdn.microsoft.com/oldnewthing/20060818-14/?p=30053#comment-411103
    "[“What do you think of the new security model in Vista?” Ask me in ten years. -Raymond]"

    So, now that it is ten years (and several Windows versions) later, what did you think about the new security model in Vista?

    1. I think it's still too soon. People are still upset by it.

  26. Joshua says:

    I thought I had nothing more to say about UAC. Turns out I was wrong. Somebody managed to make the UAC prompt declare his binary as admin via a custom root certificate. This is the kind of thing you shudder at. Any real vulnerability pathway involves also compromising one of the hundreds of certificate providers but that's not as hard as some other attacks on Windows that have been made to work in the past.

    https://labs.mwrinfosecurity.com/blog/masquerading-as-a-windows-system-binary-using-digital-signatures/

  27. Richard says:

    "when I do elevate to administrator, I'm running as the local administrator account, not as myself."

    How does that work when installing applications?
    If it not running as you then how does it install the per-user settings?
    - eg Start/Desktop shortcuts, licence key etc.

    1. skSdnW says:

      Those are not supposed to be per user if installing for all users/elevated. And any per-user data that goes in %appdata% needs to be copied from a template in programfiles/programdata the first time a user runs the app...

    2. They already have to solve this problem for the general case where an administrator wants to install an app for a non-administrator to use.

    3. See the 20+ years old "Designed for Windows" guidelines!

Comments are closed.

Skip to main content