UAC has caused a lot of buzz ever since Vista was released. Sometimes even I wonder if the topic of UAC comprises a measurable amount of the total web and email conversations about technology for the last two years ;)
The main concern about UAC has always been those pesky prompts asking your permission to do innocuous activities like deleting kernel32.dll. Sometimes you get them when you don’t want them and sometimes you don’t get them when you should. It turns out there are many ways to cause or suppress UAC prompts – this post attempts to document them all…
For software that will run in corporate environments, it is important to understand the many ways to trigger or suppress these prompts and which ones take precedent. For our course CSI-300 Foundations of the Native Windows Application Environment, I have have spent time building a catalog of the methods that are available to configure UAC. I thought I would share that with you.
Precedence: These are in order of precedence if the same setting is configured in multiple places. Where precedence is said to be “additive” it will cause an “upgrade” if the current execution level is lower, but will not “downgrade” a execution level that is already specified.
requireAdministor may result in an elevation prompt or an OTS prompt – if no UAC is approved, application does not run.
highestAvailable will only result in a prompt if the individual can elevate, otherwise they will execute the program with their own permissions.
asInvoker prevents UAC prompts and runs the target EXE with the user’s current rights (admins do not elevate).
There are a lot of complex things going on here and I have done my best to test the various scenarios to both validate the claims written in SDKs and the on the web and to tease out unstated scenarios. If you find mistakes in the below or do tests that conclude something different or have ideas for additional methods, benefits or challenges, please contact me via the contact us page.
Date |
Rev. |
Changes |
1/4/2011 |
2.2 |
External Manifests - Added Activation Context Caching |
2/17/2010 |
2.1.1 |
Correction to Internal Manifests |
11/12/2009 |
2.1 |
First Published |
Manifesting Based
Intercept: Loader
External Manifest:
Precedence Level: 1 (lowest)
Scope: Single EXE, in a specific folder on a single machine.
Configuration: Create a manifest file next to the EXE. For abc.exe, create abc.exe.manifest. For a sample manifest see this blog post.
Visibility: HIGH
Configuration/Tampering Effort: EASY-MEDIUM (File Permissions Dependent, however, UAC Virtualization Overrides Possible)
Runtime Alteration or Selection: STATIC
Intercept: Loader
UAC Options Available: asInvoker, highestAvailable, requireAdministrator
Benefits: Ease of configuration – no changes to EXE required. Also disables UAC virtualization – even when manifesting “asInvoker”.
Challenges: LOTS –> Ignored when internal manifest exists (even if internal contains no requestedExecutionLevel), can be separated from EXE, can be UAC Virtualized (usually by mistake but could also be used as an override by a non-privileged user), contents can be Prefetch Cached (quite painful)
Manifest Caching (Activation Context Caching) causes Windows to cache whether a manifest exists and should be loaded for a given EXE. Microsoft's documentation says that this cache: a) is memory based and reset by a restart, b) only caches manifest existence. However, it appears to be more complex than that as manifest caching has been observed across reboots and somehow the requestedExecution level must be kept somewhere because there is not always a smooth transition from asInvoker to requireAdministrator when editing an existing manifest.
The most reliable way to ensure that manifest caching does not get in the way is to update the file modification date of the EXE being manifested - this invalidates any cached manifest entries and causes the loader to look again.
Internal Manifest:
Precedence Level: 2 (overrides external manifest)
Scope: Single EXE, everywhere it resides
Configuration: Embed a manifest resource in the EXE. For a sample manifest see this blog post.
Visibility: VERY LOW
Configuration/Tampering Effort: HIGH (Requires PE Editor, can be foiled with self-check of code signing)
Runtime Alteration or Selection: STATIC
Intercept: Loader
UAC Options Available: asInvoker, highestAvailable, requireAdministrator
Benefits: cannot be separated from EXE, cannot be easily deconfigured. Also disables UAC virtualization – even when manifesting “asInvoker”.
Challenges: cannot be overridden by external manifest (unusual since the direction in .NET is to give almost 100% control via external manifests – but then this is pre-.NET type of manifesting)
Shim Engine Based
Shim based UAC prompting overrides manifest based because it is more specific. In theory the developer provided the manifest for everyone who would ever use their software (obviously external manifests can be added after the fact – but they are overridden by internal ones). Shims are applied to the runtime environment, rather than development time.
IMPORTANT: Shimming to “asInvoker” with any of these methods DOES NOT disable UAC virtualization as it does when using manifests.
Registry Based UAC Shims (includes: “Program Compatibility Assistant” ( PCA), “Compatibility Tab” and “Troubleshoot Compatibility” (Win7), )
Precedence Level: 3 (overrides internal and external manifesting)
Scope: Single EXE, in a specific folder on a single machine, for a specific user
Configuration: Program Compatibility Assistant ( PCA), Troubleshoot Compatibility (Win7), Compatibility Tab, Direct registry tweaks to
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Persisted
Visibility: MEDIUM (Compatibility Tab Visibility=HIGH)
Configuration/Tampering Effort: EASY-AUTOMATIC
Runtime Alteration or Selection: STATIC
Intercept: Loader
UAC Options Available: [Compatibility Modes]: RunAsInvoker (asInvoker), RunAsHighest (highestAvailable), RunAsAdmin (requireAdministrator), ElevateCreateProcess
Benefits: Easy to configure (compared to .SDB)
Challenges: Much less granular shims (compatibility layers), can be reconfigured by admin users if Compatibility tab is left enabled. unlike .SDB shims, the fully pathed location of the EXE is used for identification of what to apply the shim to, must be configured for each user of a machine
Shimming Environment Variable
Precedence Level: 4 (overrides Registry Based UAC Shims)
Scope: Individual script
Configuration: Set environment variable __COMPAT_LAYER to Compatibility Mode/Layer Name (e.g. “set __COMPAT_LAYER=RunAsAdmin”)
Visibility: MEDIUM (Must Know Location of Script)
Configuration/Tampering Effort: MEDIUM (Must Have File Permissions to Script)
Runtime Alteration or Selection: DYNAMIC (logic in script)
Intercept: loader
UAC Options Available: [Compatibility Modes] RunAsInvoker (asInvoker), RunAsHighest (highestAvailable), RunAsAdmin (requireAdministrator), ElevateCreateProcess
Benefits: Can be triggered via scripting with the ability to pick a compatibility layer. The other scripting method is to use “Runas” which only allows the equivalent of “requireAdministrator”
Challenges: Must be able to configure an environment variable in the parent process
.SDB Based UAC Shims
Precedence Level: 5 (overrides Registry and Environment Variable Based UAC Shims).
AdditiveRunAsHighest has special precedence rules in that it will upgrade all previously encountered “asInvoker” requests to highestAvailable – but it WILL NOT downgrade previously encountered “requireAdministrator” requests to highestAvailable. (In contrast, the shim RunAsHighest will downgrade requireAdministrator to highestAvailable.)
Scope: Single EXE in ANY folder on a machine where the .SDB is installed (very flexible EXE detection) for ALL users (machine global)
Intercept: Loader
UAC Options Available: RunAsInvoker (asInvoker), RunAsHighest (highestAvailable), RunAsAdmin (requireAdministrator), RelaunchElevated, ElevateCreateProcess, AdditiveRunAsHighest
Configuration: Use Compatibility Administrator to build an .SDB, distribute and install it.
Visibility: VERY LOW
Configuration/Tampering Effort: HIGH
Runtime Alteration or Selection: STATIC
Benefits: Tamperproof
Challenges: Must author, distribute and install .SDBs (not hard, but very different than dropping a file in a folder)
Process Startup Based
Process based execution is really how UAC services the legacy “runas” support. Shimming UAC causes all executions of the EXE on a given machine to behave as requested. Process based startup is more specific because it is just for a given run of the EXE. The only elevation possible is to administrator rights, highestAvailable and asInvoker are not available.
Shortcut Attributes (Advanced button, NOT the “Compatibility” tab)
Precedence Level: 6 (additively overrides manifests and shimming – will prompt for admin, but does nothing to existing requested execution level if it is unspecified)
Scope: Single shortcut (other shortcuts can be non-elevating)
Configuration: Checkbox under “Advanced” button – NOT the “Compatibility Tab”
Intercept: During execution request
UAC Options Available: equivalent of requireAdministrator
Visibility: MEDIUM
Configuration/Tampering Effort: EASY
Runtime Alteration or Selection: STATIC
Benefits: Can be easily self-configured by end users.
Challenges: can only requireAdministrator, no equivalent of highestAvailable.
Shell Menu Verbs (Right-click Menu in Explorer)
Precedence Level: 6 (additively overrides manifests, shimming and shortcut attributes – will prompt for admin, but does nothing to existing requested execution level if it is unspecified)
Scope: Execution of all files of a given type on a given machine. Via setting Shell Menu “default” it can affect all double clicking of the file type.
Configuration of Customized Verbs (edits text files in elevated Notepad):
REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\txtfile\shell\runas] @="Notepad (Elevated)"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\txtfile\shell\runas\command] @=hex(2):22,25,53,79,73,74,65,6d,52,6f,6f,74,25,5c,53,79,73,74,65,6d,33,32,5c,\ 6e,6f,74,65,70,61,64,2e,65,78,65,22,20,22,25,31,22,20,25,2a,00
Visibility: HIGH
Configuration/Tampering Effort: HIGH
Runtime Alteration or Selection: STATIC or DYNAMIC depending on what verbs are made available. The default and verb can be set to elevate.
RE-Configuration of Standard Verbs (changes default “open” on text files to edit using elevated Notepad):
REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\txtfile\shell] @="runas"
[-HKEY_LOCAL_MACHINE\SOFTWARE\Classes\txtfile\shell\open]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\txtfile\shell\runas] @="Open"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\txtfile\shell\runas\command] @=hex(2):22,25,53,79,73,74,65,6d,52,6f,6f,74,25,5c,53,79,73,74,65,6d,33,32,5c,\ 6e,6f,74,65,70,61,64,2e,65,78,65,22,20,22,25,31,22,20,25,2a,00
Visibility: HIGH
Configuration/Tampering Effort: HIGH
Runtime Alteration or Selection: DYNAMIC (users chooses whether to pick elevated choice or not)
Intercept: During execution request
UAC Options Available: equivalent of requireAdministrator
Benefits: User has the option during each use on whether or not to elevate.
Challenges: User must remember to right click and select an elevated option, can only requireAdministrator, no equivalent of highestAvailable.
Scripting
Precedence Level: 7 (additively overrides manifests, shimming, shortcut attributes and Shell Menu Verbs– will prompt for admin, but does nothing to existing requested execution level if it is unspecified)
Scope: Individual execution of given EXE.
Configuration:
VBScript (.VBS):
set objShell = CreateObject("Shell.Application") objShell.ShellExecute "notepad.exe", "", "", "runas", 1
Shell Script (.CMD/.BAT) with Microsoft elevation PowerToy:
Visibility: LOW
Configuration/Tampering Effort: MEDIUM
Runtime Alteration or Selection: DYNAMIC
Intercept: During execution request
UAC Options Available: equivalent of requireAdministrator
Benefits: Can decide whether to attempt elevation depending on whether it is needed or not.
Challenges: can only requireAdministrator, can approximate highestAvailable with “IfUserPerms.vbs” linked below.
Related Resources and References
IfUserPerms.vbs - Script to passively check if user is currently a non-elevated admin. Can also check the presence and seperately the enabled status of special privileges as well as any group membership.
Sample Manifest Template – self documented via comments, includes new Windows 7 Compatibility manifesting.
Manifests can be UAC Virtualized
Microsoft Elevation PowerToy and Technet Article
Please report errors or additional information via the contact us page.
|