PsExec, User Account Control and Security Boundaries

I introduced the -l switch to the PsExec tool about a year and a half ago as an easy way to execute processes with standard-user rights from an administrative account on Windows XP. PsExec uses the CreateRestrictedToken API to create a security context that's a version of the one your account is using, but without membership in the local Administrators group or any administrative privileges. A process running in that security context has only the privileges and accesses of a standard user account.

There's one catch to the virtual sandbox that the restricted token creates: Processes running in the sandbox arerunning as you, and thus can read and write any files, registry keys, and processes to which your account has access.That caveat creates gaps in the sandbox walls, and malicious code could take advantage of these gaps to escape andbecome a full Administrator. So why do I still recommend using the PsExec feature to run processes with limited rightson XP when you use an administrator account instead of a standard user account? Because this type of sandbox hasn'tbeen widely used, malware authors haven't bothered to write the code necessary to escape the sandbox walls.

However, Windows Vista changes that situation because it uses an enhanced form of this sandbox in User AccountControl (UAC) and Internet Explorer (IE) Protected Mode. With UAC, all users, including administrators, run with standard user rights. For executables that require administrative rights, UAC asks the user's permission for it to run with administrative rights.

This act of giving an executable administrative rights is called elevation in UAC. When you elevate, you create processes that have administrative rights on the same desktop as those that have standard user rights. Processes elevated from a standard user account run in a different accountfrom those with standard user rights, so the Windows security model defines a wall around the elevated process that prevents the non-elevatedprocesses from writing code into those that are elevated. However, it doesn't prevent non-elevated processes from sending fake input into elevatedprocesses, nor does it create a sandbox around the non-elevated processes of administrative users to stop the processes from compromising theadministrator's elevated processes. Vista therefore introduced Windows Integrity Controls, which supply additional fencing for the sandbox.

In Vista's integrity model, every process runs at an integrity level (IL) and every securable object has an IL. The primary integrity levels are low,medium (the default), high (for elevated processes) and system. The integrity mechanism prevents lower-IL processes from sending all but a fewinformational window messages to the windows owned by processes of a higher IL. It also only allows a process to open an object for write access ifthe process IL is equal to or higher than that of the object. And processes can't open processes of a higher IL for read access.

The new version of PsExec takes advantage of the enhanced Vista sandbox when you specify the -l switch, running the executable you specifywith a standard user token at low IL. The sandbox PsExec creates is almost identical to the one surrounding IE Protected Mode, and you can feelyour way around the walls by launching a command prompt or regedit at low IL and seeing what you can modify.

With the exception of processes and threads, the wall doesn't block reads. That means that your low-IL command prompt or IE Protected Mode can read objects that your account can, including a user's documents and registry keys. Even the ability of a process at low IL to manipulate objects of a higher IL isn't necessarily prevented. You can read more details of these types of sandbox breaches in my blog at https://blogs.technet.com/ markrussinovich/archive/2007/02/12/638372.aspx.

So if your elevated processes are susceptible to compromise by those running at a lower IL, why did Vista go to the trouble of introducing elevations and ILs? Microsoft wants to lead us to a world in which everyone runs as standard user by default, and all software is written with that assumption. Without the convenience of elevations, most of us would continue to run with administrative rights all the time.