By Michael Cherry [bio]
Posted: Jan. 16, 2006

• Sidebar: Running Windows XP as a Non-Admin
• Illustration: Application Verifier

The following is the full text of an article published by Directions on Microsoft, an independent research firm focused exclusively on Microsoft strategy & technology. Each month we make one or more key articles available to non-subscribers.

The Problem of Privilege

Windows NT, Windows 2000, and Windows XP all allow different users to be assigned different privileges, such as rights to create a new account, install software, or open a file for backup. In addition, special privileged user accounts (system, local, and network service) are available for Windows' Service Control Manager, which runs various OS services and processes for all users and applications under these accounts.

Ideally, a user should use an account with administrator-level privileges for only the limited amount of time it takes to do administrative tasks, such as the following:

• Installing or upgrading the OS, including installing new drivers, OS components, and applications
• Configuring critical OS and application parameters, including creating new user accounts, managing file access, and maintaining system logs
• Repairing the OS and applications, including installing patches and service packs.

When users run an OS with too many privileges, they can mistakenly delete key OS files or unwittingly install malicious software if they encounter an exploit of a bug or vulnerability. For example, a user running as an administrator might encounter a Web page that silently installs a remote-control program. Because the browser and the application installer run with the user's privileges—in this case, the privileges of the powerful administrator account—the malicious software can be installed and can take full control of the computer. Furthermore, the malicious software can change the configuration of the OS, install additional malicious software, read and change any file on the computer, and cover its tracks to make itself almost impossible to detect.

In contrast, an account with limited privileges cannot mistakenly delete key OS files or make changes to the system's configuration. Malicious software that attempts to exploit a bug or vulnerability can perform only tasks permitted by the account's privileges. For example, if a user with an account that does not permit software installation encounters malicious software such as spyware, the spyware is unable to install itself on the computer.

Although Windows allows users to run with the least privilege necessary, few do. (For more on running Windows XP with a user account, see the sidebar "Running Windows XP as a Non-Admin".) The main reason is that Microsoft did not discipline developers, including its own, to write applications with least user privileges in mind. Instead, many Windows applications require the user to be an administrator even for trivial tasks; for example, Windows requires administrator privileges for changing the current time zone. Because earlier versions of Windows (such as Windows 95) lacked any security architecture and because Microsoft wanted to maintain as much backward compatibility as possible, almost all Windows users have administrative privileges by default (although in some organizations, Group Policy is used to limit what tasks users can perform). For example, the user accounts created during the initial installation of Windows XP are administrator-level accounts, and new user accounts created later are, by default, administrator-level accounts.

User Account Control

To improve the security of Windows and bring it in line with competitors' OSs, Microsoft is redesigning Windows Vista to support a feature called User Account Control (UAC), which creates a special type of account that runs in Admin Approval Mode (AAM). By default, an account in AAM runs as a limited user, but when the user needs higher privileges, she can supply administrator credentials or consent, depending on Group Policy settings, that will permit her to perform an administrator-level task, such as installing new software. These higher privileges are only in effect for the specific task and do not affect other programs. When the task is complete—for example, the new software has been installed—the elevated process running that task ends and the elevated privileges are gone.

To ensure that UAC will improve the security of Windows, Microsoft must determine which tasks should be restricted to administrators, make it easier to temporarily elevate privileges, and isolate messages that flow between Windows applications. Because Microsoft places such a high value on application compatibility—that is, making sure that changes to Windows do not break applications—it is also working to ensure that legacy applications can run without administrator privileges.

Determining privileged tasks. While some tasks, such as installing or removing applications properly require administrator-level privileges under Windows XP, other tasks that currently require administrator privileges could be safely modified to enable their execution by less-privileged users. For example, in order to change the system time a user traditionally needs administrator-level privileges. But many users travel with a laptop or portable computers to a different time zone. To enable this scenario, Vista will allow non-administrator users to control the computer's time zone settings.

Temporarily elevating privileges. Users should not have to log off from a user-level account and log on with an administrator account to perform an administrative task. Instead, Vista will allow them to click on a button or access a dialog box, provide administrator credentials, and complete the task. Administrative privileges will be in effect only for the specific task, and when it is completed, the user will revert to their user-level privileges.

Isolating messages. The Windows OS communicates with applications via messages that are placed in a queue, retrieved, and processed by the application. For example, when a user clicks in a window, a "click" message is placed in the queue for that window. In current versions of Windows, any application running on Windows can send a message to any other application, even if the other application doesn't want those messages. Under Windows Vista, an application or process running with a lower privilege cannot use messages to send input to an application or process with a higher level of privilege. This prevents lower-level programs from performing tasks or executing code at the higher privilege level.

Ensuring legacy applications run. Some current Windows applications require a user to have administrator-level privileges even for relatively trivial tasks, often due to sloppy practices on the part of the developer. For example, some applications store user-specific information, such as date format preferences, in areas of the Registry or the file system in which data can only be changed with administrator-level privileges; these areas are intended for shared or systemwide information only.

To allow such applications to run on Windows Vista, UAC will create a virtual store for each user that holds a copy of portions of the Registry and file system. When a legacy application running with user-level privileges attempts to access restricted system areas, Windows will automatically redirect the request to the user's virtual store, leaving the actual system store untouched.

But providing workarounds for application compatibility has some risks. First, workarounds like the virtual store are complicated and therefore a possible source of reliability problems, particularly for utilities that have to work with both the real and virtualized stores. In addition, extra Windows code that supports backward-compatibility workarounds can itself introduce flaws, such as buffer overflows, that open Windows to attack.

Applications May Need Updates

Although the virtualization of Registry keys and system file locations for UAC should catch inappropriate storage locations for user data and provide a level of compatibility for existing applications, developers should not count on virtualization to resolve all privilege issues, nor should they gamble that the feature will be available in all future versions of Windows. Instead, they should think of virtualization as providing a transition for existing applications, which should be updated to work with limited user privileges in their next release.

To aid developers in finding privilege problems before Vista ships, the company is providing an Application Verifier that developers can use to find subtle programming errors, such as memory corruption and security vulnerabilities. It monitors an application's interaction with Windows, profiles the application's use of the Registry, the file system, and other OS objects, and predicts how well the application will perform when the user is not an administrator. (For an example of an Application Verifier report, see the illustration "Application Verifier".)

In addition, developers may need to ensure the following:

• Application functions that truly require administrator-level privileges are isolated from less critical tasks
• Configuration activities that require administrator privileges are performed during installation; user configurations, such as those performed the first time the program is run by a user, do not require administrator rights
• Applications do not perform an explicit check for administrator-level privileges before allowing the application to run.

In addition, applications should not use their own update or patching mechanism, but should rely on the Windows Installer for installation and patching, as the Windows Installer works with the system to ensure installation or patching is completed at the correct privilege level.

Resources

Best practices and guidelines for developing applications to run in a least-privileged environment are described at msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/AccProtVista.asp.

Guidelines for making existing applications run with UAC are described at www.microsoft.com/technet/windowsvista/deploy/appcompat/acshims.mspx.

The Application Verifier can be downloaded from www.microsoft.com/downloads/details.aspx?FamilyID=bd02c19c-1250-433c-8c1b-2619bd93b3a2&DisplayLang=en.