User Account Control Is More Than You Think
UAC is designed to meet a number of goals:
-
Increase the number of end users that can run as a non-administrator the majority of the time.
-
Decrease the number of scenarios that require elevation to an administrative account.
-
Make elevation considerably easier-automatic if possible-than the current kluges using runas.exe or just logging out from one account and in with another to bridge the gap until ISVs fix their applications.
-
Provide some protection of applications running as an administrator from those that are not.
-
Enable certain exposed applications to run with even fewer privileges whenever possible.
Only one of those goals deals with the actual elevation task. Yet, the elevation, when an application asks for additional privileges, is what people complain about. The first, overarching, goal has nothing to do with elevation. It is only to enable more people to run as non-admins more of the time.
The next two goals are designed to make the user experience of running as a non-admin as palatable as possible. Finally, we have two goals that are designed to protect applications that are particularly exposed.
What is important about these goals is that only two of them are related to the feature that is popularly seen as "UAC." Goal number 3 is about making elevation easier than what it was in Windows XP, and goal number 4 is about protecting applications that are running elevated. The remaining goals have to do with something that is essentially non-technical, or with a technology most people never notice. Each of them required changes to the operating system, however.
In the remainder of this section we will investigate the changes that were made to the OS to meet each of these goals. Some changes contribute to several of the goals, and some contribute to only one or a few.
Elevation
Core to UAC is the ability to easily elevate to a full administrator. By default, even members of the administrators group are not running with a full administrative token. This means that some tasks that would have been possible under Windows XP do not work under Windows Vista the same way. Consider, for instance, Figure 1.
Even when a user is logged on as a member of the Administrators group they are by default placed in what is called admin approval mode. The user's security token, by default, has the Administrators SID marked as Deny, as shown in Figure 2. This means that it is used only to deny access, never to allow it.
A security token with the Administrators SID set to Deny is called a "filtered token." A user with such a token cannot do anything more on the system than a regular user. Note also that the privileges shown in Figure 2 contain only a set of relatively benign privileges associated with a regular user.
If a user needs to perform an administrative task, the user needs to elevate. The elevation can be initiated by the program that is being executed, in several ways that we shall see later. It can also be initiated by the user, by right-clicking the program and selecting "Run as administrator," as shown in Figure 3.
Initiating elevation of a task causes the OS to switch the user into what is known as the "secure desktop." . It is sufficient to know that all user applications run within a structure known as the "desktop." Each user has a separate desktop, and the OS has one that it uses for security sensitive tasks-the secure desktop. The secure desktop is used to host security sensitive functions, such as the logon dialog boxes, and UAC elevation prompts. The secure desktop cannot be programmatically driven by ordinary applications. This means that while applications that run on a user's desktop can interact with user interface components of other applications on the same desktop, they cannot do the same with user interfaces shown on the secure desktop. For this reason, Windows Vista, by default, puts the elevation prompt on the secure desktop, as shown in Figure 4.
Knowledge of the secure desktop allows you to answer the very common question of why the screen goes dark. You are actually not looking at your screen at all. The OS takes a screenshot of your screen, switches to the secure desktop, puts a grey mask over the screenshot, and shows that as the background of the secure desktop. This explains why a moving user interface component appears to be frozen when the UAC elevation prompt is up.
You can disable the switch to the secure desktop using Group Policy. The setting is under Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options/User Account Control: Switch to the secure desktop when prompting for elevation. This is actually necessary if you need to use Vista's speech recognition feature to control user interface elements. However, for most users, it is highly recommended that you leave the defaults in place.
A very common complaint of Windows Vista is that the switch slows down the computer. In our testing, (using a virtual machine running in Virtual PC 2007 on a relatively moderate laptop, as shown in Figure 4) the switch takes less than half a second. On reasonable hardware, it should be virtually instantaneous. If you find that it takes a noticeable amount of time, you most likely have a video driver issue. Check with your computer Original Equipment Manufacturer (OEM) or the manufacturer of your video card to see if there is an updated driver available.
Once the process is elevated it has a full administrative token, as shown in Figure 5, which is a screenshot of Microsoft's Process Explorer, showing the token for an elevated command prompt process.
The prompts shown in Figures 1 and 4 are both for built-in components that are signed by Microsoft. Signed, non-Microsoft binaries have a prompt that looks almost identical, but the field underneath the "Windows needs your permission to continue" prompt is grayer. This extremely slight color difference is meant to alert users that the prompt is not as highly trusted.
Far easier than telling Microsoft v. non-Microsoft signed binaries apart is telling that a binary is not signed at all. The elevation dialog box for an unsigned binary is shown in Figure 6.
When attempting to elevate an un-signed binary the elevation dialog box has a yellow bar at the top and the text is different. The dialog box also looks different, as shown in Figure 6.
By the way, Iexplore.exe is Internet Explorer, and no, it is not actually unsigned. It shows up this way on purpose to warn people not to elevate Internet Explorer, according to Microsoft.
The theme of the UAC dialog boxes is used throughout the operating system. A very similar dialog box is used when installing unsigned drivers. This dialog box, shown in Figure 7, has a red bar, and presents similar information to the UAC dialog boxes.
The elevation dialog boxes are also used in Internet Explorer (IE) when it attempts to install an ActiveX control. IE will first prompt that the site is attempting to install the control using the familiar information bar that was introduced in Windows XP Service Pack 2, shown in Figure 8.
The gold bar in Figure 8 is shown only if the user is an administrator in admin-approval mode. If the user is a standard user, or if the admin chooses to install the control, we proceed directly to a UAC prompt. This prompt is, unfortunately, the least informative prompt in all of UAC, possibly all of Windows. It is shown in Figure 9.
Exactly how you are supposed to make any intelligent decisions based on this prompt is quite unclear and it is even more unclear if it pops up from a Web site that is less obvious than the one in Figure 9. Information about what exactly the system is trying to install is, for all practical purposes, lacking. Instead, the system shows a Globally Unique Identifier (GUID). To make any sense of this you would have to write it down, and then search the Internet for any information on it. However, just as in the case shown in Figure 9, you would find no information in most cases. The user is, in other words, left entirely on his or her own trying to decide whether to accept this object. If he does, he will get to see the naked dancing pigs, so it is unlikely that security will stand a chance.
To be completely fair here, however, we should point out that if you hit Continue in the dialog box shown in Figure 9, you get another dialog box that asks again if you want to install this control. That dialog box is from Internet Explorer, and it does show the name of the control.
Non-Admin Elevation
All the dialog boxes for elevation shown so far are those that appear to a filtered admin, a member of the administrators group when UAC is enabled. As mentioned earlier, this mode of operation is called admin approval mode. Running day-to-day in admin-approval mode is definitely a security improvement versus the way we ran in Windows XP: admin always mode. However, when elevating an application in admin-approval mode, the application receives the exact same user environment as the applications running with a filtered token. Theoretically, exploits can be crafted that poisons a filtered admin environment such that when the user elevates, the exploit also gets elevated. We are not aware of any such exploits as of this writing. Nevertheless, it is very likely that some will surface eventually. Only by running as a standard user can you combat those exploits. Users are not made standard users by default because too many applications currently require elevation, and it is felt that giving users two accounts-one standard user, one admin-is too cumbersome.
When running as a standard user the process token looks almost identical to the filtered admin's token, with the exception that the standard user does not have the Administrator's SID in the token at all. Applications are elevated with exactly the same process as before, but the prompt now prompts for credentials instead, as shown in Figure 10.
The elevation prompt is still on the secure desktop and so is protected against sniffing attacks. Contrary to runas.exe under Windows XP, elevation also works against an administrator account that does not have a password, although the prompt still will show a password field. The prompt also shows all the administrators on the computer. It even starts scrolling if there are more than five. Unfortunately, there is no way to turn this off and to require that the user know a valid administrative account name.
A process that is elevated by a standard user still runs within the user's desktop, and is a child process of Windows Explorer, as shown by the tree view in Process Explorer in Figure 11. Note the integrity label on the various processes under explorer.exe. Elevated processes run with a high integrity label and use the environment of the administrative user. For example, the registry hive HKEY_CURRENT_USER, as seen by an elevated process, will be the hive of the administrative user, not the standard user who initiated the elevation. This provides some protection against poisoning attacks.
Since the elevated applications still run on the standard user's desktop there is still not a separation of processes, and a non-elevated process can still interact with an elevated process. To achieve separation you would need to log out as the standard user and log on as the administrative user. You may also do this with fast user switching (FUS). Unlike Windows XP, FUS is enabled on domain-joined computers.
Special Topics in Elevation
Elevation is designed to be used programmatically, by developers, and in binary applications only. For instance, if you attempt to launch a registry script (REG), or vbscript (VBS), elevated, you cannot do so. You would have to launch an elevated command prompt, and then open the application from there. The option to "Run as administrator" is not present for REG and VBS files.
Using a simple registry hack, however, you can add the Run as administrator option to any file type you want. To do so you need to add a runas command to the registry entry defining the file type.
First, open the registry and search for the extension to the file type you wish to enable Run As for. For instance, you will find VBS files under HKEY_CLASSES_ROOT\.reg. Look at the default value in that key. It lists the file type name. In this case, it is regfile. Now search for regfile, and you will find HKEY_CLASSES_ROOT\regfile. Expand that key, and then expand the shell and open keys. Look at the default value of the open key. It should be regedit.exe“%1”. The command to elevate it is exactly the same, but you need to tell the shell to elevate the application parsing this file first. To do that, you add a runas key under the shell key and copy the same default value into it. Finally, you need to create a value called IsolatedCommand in the same location, and copy the same value to it.
This can be automated using a registry. For instance, here is a registry script that adds the Run as administrator context menu item to VBS and REG files:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\regfile\shell\runas\command]
@="regedit.exe \"%1\" %*"
"IsolatedCommand"="regedit.exe \"%1\" %*"
[HKEY_CLASSES_ROOT\VBSFile\Shell\runas\command]
@="WScript.exe \"%1\" %*"
"IsolatedCommand"="WScript.exe \"%1\" %*"
If you are interested in the syntax of these registry scripts, and much more, we warmly recommend the "Windows XP Commands" reference, at
http://www.ss64.com/nt/index.html.
New Privileges to Delegate Common Tasks
To meet the overarching goal of enabling more people to run as a non-admin more of the time, several things needed to happen. One of the most fundamental is the addition of some privileges.
Windows Vista adds five new privileges, over Windows Server 2003. They are as follows:
-
SeTrustedCredManAccessPrivilege: "Access Credential Manager as a trusted caller." This privilege allows a subject to access the credential manager to back up and restore all the entries in it. Obviously, it should be granted very sparingly, if at all. By default it is not granted to any user. A few processes, such as WinLogon (the Windows logon application), smss.exe (Windows session manager), and lsass.exe (local security authority sub-system) have it by default.
-
SeRelabelPrivilege: "Modify an object label." This privilege gives a subject the ability to modify the integrity label on an object. It is extremely sensitive, and allows the holder to compromise the entire computer by modifying labels. It is also not granted to any users by default, but is carried by several processes, including: smss.exe, csrss.exe (client-server runtime process), lsass.exe, and lsm.exe (local session manager).
-
SeIncreaseWorkingSetPrivilege: "Increase a process working set." This privilege allows a user to increase the working set, the number of pages of memory, allocated to a process. This is an important part of UAC. It permits users to run applications that need to increase their working set at run time.
-
SeTimeZonePrivilege: "Change the time zone." The poster child of why you could not run as a limited user in Windows XP was that you “can't "even change the time zone." Way back in the days of the original release of Windows NT, Microsoft decided that modifying the system time was a privileged operation and should only be granted to administrators. This made sense because if you can change the system time, you can modify audit events. Try it some time: generate some audit events, then set the clock back a few hours, and generate some more events. The newest events will be on top of the log, but according to the timestamp on the events they occurred before the events that come after them. Changing the time zone, however, only changes the offset of the system time from Zulu time. This does not modify audit events because they are logged using Zulu time anyway. Thus, while changing the system time is a sensitive operation, changing the time zone is not. Yet, until Windows Vista, the same privilege, SeSystemtimePrivilege, governed both operations. In Windows Vista the code was factored and a new privilege, for changing the time zone, was added. Users have the SeTimeZonePrivilege, but only Administrators and LocalService have SeSystemtimePrivilege. The reason there is a privilege for this is so that the ability to change the time zone can be disabled. For example, when using parental controls, standard users no longer have the ability to change the time zone; this helps to avoid the situation where children change it to use the computer longer.
-
SeCreateSymbolicLinkPrivilege: "Create symbolic links." Windows Vista supports full symbolic links (symlinks), contrary to earlier versions of Windows which supported only junction points. Junction points are formed from the drive signature and are therefore persistent across drive letter changes, which is important. Junction points are designed to be used with systems where you have more than 26 volumes. However, they can only point to local resources. Symlinks can point to anything across the file system and the network. For instance, you can have a symlink pointing to a network share, as in this example:
mklink /d foo \\server\share\directory
Symbolic links have always been associated with certain security concerns. Not only people, but also software, may make security decisions based on where in the name space an object resides. For instance, if an administrator runs a tool that changes the owner or access rights on a folder hierarchy, and a malicious user has created a symbolic link inside that hierarchy, the security of the computer can be compromised if the tool evaluates the symbolic link and traverses somewhere else. A user might, for example, have a symlink inside a public directory that points to %windir%. If an administrator changes the permissions on the public directory to fix a problem, and the tool traverses the symlink, permissions would also be changed on %windir%. For this reason, the ability to create a symlink should be restricted to only certain trusted users. The SeCreateSymbolicLinks privilege is designed to allow delegation of the right to create symlinks.
Application Factoring
Another critical component of UAC is application factoring. Many applications required administrative privileges, even though the vast majority of users running the application did not use the functionality that required administrative privileges. By factoring out those components into either separate applications, or into separate tasks, an ordinary user can use the rest of the features of the application without having to be an administrator.
UAC introduces the concept of a "COM Elevation Moniker." Simply put, a COM Moniker leverages the Component Object Model (COM), a programming concept that allows developers to separate tasks into reusable components. By factoring out tasks requiring administrative privileges into separate components, a developer can permit a user to run much of an application without elevating, while easily allowing elevation when needed.
Consider the screenshot in Figure 13. Figure 13 shows a COM Moniker in Task Manager. When a non-administrator, or an administrator in admin-approval mode, launches Task Manager, it shows only that user's processes. To show processes from other users is an administrative operation. To do so easily Task Manager links the button "Show processes from all users" to a COM Moniker, which will launch an elevated instance of Task Manager, as shown in Figure 14.
COM Monikers are heavily used in the operating system to factor functionality that requires administrative privileges while allowing the remainder of the application to be used without elevation. Note that the elevation happens within the same context though. This means that there is a potential for privilege leaks across a COM Moniker elevation. Again, this is further reason to run as a standard user most of the time.
Virtualization
For good and bad, there are thousands of applications already out there for the Windows platform. Far too many of them are designed, written, and tested under the assumption that the user running them will be an administrator. The most common reason why these applications do not work as an non-admin is that they try to write to protected areas of the computer-areas that only admins have access to.
To make applications that exhibit only these types of flaws work under a non-admin user on Windows Vista, the OS gives them access to a virtual copy of certain parts of the computer. %programfiles%, %systemroot%, and portions of HKEY_LOCAL_MACHINE\Software may all be virtualized for applications that need it. To find out if a specific registry location can be virtualized, check the value of the REG_KEY_DONT_VIRTUALIZE flag using the reg.exe flags command. In our testing, we found there are 4,803 keys in the registry that permit virtualization but the total number may vary depending on what you have installed. If a registry key has its flag set to True, or Empty, it cannot be virtualized. One potential issue with virtualization happens when you edit the registry on a Windows Vista system with a Windows Server 2003 or Windows XP system. These systems do not support the flags, and will clear them. This means that virtualization will fail for all keys that were edited on a down-level system.
Virtualization is not something applications ask for. Legacy applications get it if they request to write to places they should not. Virtualization is enabled automatically for 32-bit applications run by interactive users. No other applications are virtualized. If an application attempts to write to a file in a virtualized location, the file will actually be stored in %userprofile%\AppData\ Local\VirtualStore\. That means that all virtualized applications of a particular user will see the same virtual stores, but virtualized apps run by another user do not see the same changes.
Note here that virtualization only happens if an application attempts to write to a location that it does not have access to. If an application never writes to any of the potentially virtualized locations, there is no virtualization happening. Likewise, before attempting to read or write to a location that can be virtualized, the OS checks to see if there is a virtual copy already. If there is, the OS uses the virtualized copy and does not even attempt to use the actual location.
Virtualization is considered a "temporary" feature by Microsoft. It is available only to provide compatibility for older applications until they are updated. The plan is to remove virtualization in a future version of Windows.
Integrity Labels and Low Rights Apps
Integrity labels are discussed in several places in the book. They are a mandatory integrity control (MIC) mechanism, similar to that proposed by Biba in 1975. A non-elevated process typically has a medium integrity label. Likewise, objects that are not specifically marked with an integrity label are considered medium integrity. Accordingly, it can read and write only medium integrity and lower data. An elevated process receives a high integrity label. A process cannot write to an object with a higher integrity label. Therefore, a non-elevated process cannot write to objects, such as memory, owned by an elevated process.
Some processes receive a low integrity label. Currently, this is used only by IE. IE is also the only built-in process that marks objects it saves with an integrity label. This prevents IE from writing to almost all objects on the computer. This is part of what is referred to as "Protected Mode," which you may have noticed in the status bar of IE if you run it on Vista. The intention is that several other exposed user applications, such as MSN Messenger and parts of Office, will eventually run with low integrity labels as well.
Even objects created during setup of the OS or an application do not get an integrity label stamped on them by default. Doing so would create problems. For example, a setup process for a game may create a file to hold high scores. If that file were marked with high integrity (the label of the setup process), the game itself, running in medium integrity, would be unable to write to it.
Note that if you disable UAC you also disable protected mode in IE. Disabling UAC and running IE as an administrator means that you have essentially the same level of exposure as in Windows XP. Disabling UAC and running IE as a standard user means that exploits coming in through IE can corrupt any location in the user's profile.
Special Treatment of Built-in Administrator
As part of UAC, Windows Vista modifies how the built-in Administrator account, RID 500, is treated. On a clean installation of Windows Vista the builtin Administrator is disabled.
During an upgrade the disposition of the built-in Administrator account depends on the disposition of the account at the start of the upgrade and the status of other administrative accounts on the computer. If the built-in Administrator account is the only enabled, local account in the Administrators group that is allowed to log on locally, it is left enabled and placed in admin-approval mode. If other active local administrative accounts exist, the built-in Administrator account is disabled.
The built-in Administrator account is also treated specially in safe mode. Table 1 summarizes when the account can be used to log on in safe mode.
Table 1: Treatment of Built-In Administrator in Safe Mode
 Open table as spreadsheet
|
COMPUTER STATE
|
BUILT-IN ADMINISTRATOR STATE
|
OTHER LOCAL ADMINS AVAILABLE
|
LOGON WITH BUILT-IN ADMINISTRATOR IN SAFE MODE?
|
|
Standalone
|
Enabled
|
Does not matter
|
Yes
|
| |
Disabled
|
Yes
|
No
|
|
Domain joined
|
Disabled
|
Does not matter
|
No
|
| |
Enabled
|
Does not matter
|
Yes
|
The special treatment of the built-in Administrator account means that organizations must put a little more planning into recovery to ensure that if they decide to use safe mode, there is an account available to log on with. On the plus side, the long-standing physical access exposure of the default blank password on the built-in Administrator account in Windows XP is now gone.
No More Power Users
Power Users were introduced early in the Windows NT history. The idea was to create a group that had enough privileges to perform certain sensitive operations on the system, but that were not true administrators. As good an idea as this was, it never worked. Power Users are administrators that have not made themselves administrators yet. It takes milliseconds for an exploit to elevate from a Power User to an administrator. Many people inside Microsoft called Power Users "admins lite."
It is no wonder then that the Power Users group was almost entirely deprecated in Windows Vista. Power Users have almost no privileges and permissions by default. There are a few straggling positions left over by accident, and those will be gone soon as well. It is likely that in the next version of Windows, Power Users will be entirely gone.
The reason Microsoft did not remove the Power Users group entirely in Windows Vista is that many organizations put their users in that group. Those organizations may have granted additional permissions to that group and if Microsoft were to remove the group entirely those organizations would pay a huge cost to transition their permissions. Therefore, the best option was to remove all the default permissions.
|
