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 are
running 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 and
become a full Administrator. So why do I still recommend using the PsExec feature to run processes with limited rights
on XP when you use an administrator account instead of a standard user account? Because this type of sandbox hasn't
been 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 Account
Control (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 account
from those with standard user rights, so the Windows security model defines a wall around the elevated process that prevents the non-elevated
processes from writing code into those that are elevated. However, it doesn't prevent non-elevated processes from sending fake input into elevated
processes, nor does it create a sandbox around the non-elevated processes of administrative users to stop the processes from compromising the
administrator'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 few
informational 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 if
the 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 specify
with a standard user token at low IL. The sandbox PsExec creates is almost identical to the one surrounding IE Protected Mode, and you can feel
your 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.
End of Article
Register
