PsExec, User Account Control and Security Boundaries
I introduced the -l switch to PsExec 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. In Running as Limited User – The Easy Way I described how PsExec uses the CreateRestrictedToken API to create a security context that’s a version of the one your account is using, only without membership in the local administrators group or any of the privileges, such as Debug Programs, that are assigned to administrators. A process running with that kind of security context has the privileges and accesses of a standard user account, which prevents it from modifying system files and Registry keys or exercising privileges, like loading a device driver, that only administrators can perform.
There’s only one catch to the virtual sandbox the restricted token creates: processes running in the sandbox are running as you, and so can read and write any files, Registry keys, and even other processes to which your account has access. That caveat creates major gaps in the walls of the sandbox and malicious code written with awareness of the restricted environment could take advantage of them to escape and become full administrator. An easy way out is for the malware to simply use OpenProcess to gain access to one of your processes running outside the sandbox and to inject into it code and a thread to execute the code. Because your other processes are running as you and the Windows security model creates default permissions that grant your account full access to your processes, a sandboxed process will be able to open them. Another way out is to send window messages from the limited process to a normal process, like Explorer, and drive the normal process with synthesized mouse and keyboard input so that it executes code at the direction of the malware.
Given these holes, why do I still recommend using the PsExec feature to run processes with limited rights on Windows XP if you would rather use an administrator instead of standard user account? Because this type of sandbox has not been commonly used, malware authors haven’t bothered with writing the code necessary to escape and so they run into the walls.
Windows Vista changes that, however, because it uses an enhanced form of this sandbox in User Account Control (UAC) and Protected Mode Internet Explorer (IE). Let’s look at Vista’s version of the sandbox, how PsExec’s update lets you run programs in it, and explore its security implications.
UAC creates an alternate model where all users, including administrators, run with standard user rights. Executables that require administrative rights include a requestedExecutionLevel key in their manifest - XML embedded in their executable - that specifies “requireAdministrator”. When an administrator executes such an image, in its default configuration UAC presents a Consent dialog that asks permission for the image to run with administrative rights. Standard users see a similar dialog, but must enter the credentials of an administrative account to unlock administrative rights.
The act of giving an executable administrative rights is called “elevation” in UAC. Whether you elevate from a standard user account (Over the Shoulder – OTS - elevation) or from an administrative account (Admin Approval Mode – AAM - elevation), 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, the standard Windows security model does not 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. Windows Vista therefore introduces the Windows Integrity mechanism, which supplies additional fencing for the sandbox surrounding less-privileged processes.
In Vista’s integrity model, every process runs at an integrity level (IL) and every securable object has an integrity level. The primary integrity levels are low, medium (the default), high (for elevated processes) and system. The windowing system honors integrity levels to prevent lower-IL processes from sending all but a few informational window messages to the windows owned by processes of a higher IL, calling this protection User Interface Privilege Isolation (UIPI). The security model also changes in Vista to only allow a process to open an object for write access if the process IL is equal to or higher than that of the object. Further, to prevent access to secrets stored in memory, processes can’t open processes of a higher IL for read access.
If you add the Integrity Level column to Process Explorer’s display, as seen in the screenshot below, you can see that system processes, including Windows service processes, run at System IL. Most processes of your logon session run at Medium, any processes you elevated are at High, and Internet Explorer (IE) runs at Low when you have Protected Mode enabled. You can use the built-in icacls.exe utility to view and change the ILs of files and directories and the Sysinternals AccessChk tool shows ILs of files, directories, registry keys, and processes. Objects have a default IL of medium and you can use AccessChk’s -e option to search for objects that have an explicit IL.
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 Protected Mode IE and you can feel your way around the walls by launching a command prompt or Regedit at low IL and then seeing what you can modify. For example, I launched the command prompt seen below at low IL with this command: psexec -l -d cmd.exe
I first determined my profile’s temporary directory with the “set” command. When I tried to create a file in that directory I was denied access because the directory has a default IL of Medium, which is indicated by the fact that there’s no IL specified in Icacl’s output. Then I changed to Protected Mode IE’s temporary directory, which has an IL of Low, and successfully created a file.
As you experiment you’ll find that your actions are limited, but there are some design boundaries that you should be aware of. First, with the exception of processes and threads, the wall doesn’t block reads. That means that your low-IL command prompt or Protected Mode IE can read objects that your account (the standard-user version if you’re a member of the administrator’s group) can. This potentially includes 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. Since processes running at different integrities are sharing the same desktop they share the same “session”. Each user logon results in a new session in which the processes of the user execute. The session also defines a local namespace through which the user’s processes can communicate via shared objects like synchronization objects and shared memory. That means that a process with a low IL could create a shared memory object (called a section or memory-mapped file) that it knows a higher IL process will open, and store data in the memory that causes the elevated process to execute arbitrary code if the elevated process doesn’t properly validate the data. That kind of escape, called a squatting attack, is sophisticated, requires the user to execute processes in a specific order and requires knowledge of the internal operation of an application that is susceptible to manipulation through shared objects.
However, let’s be clear that no matter how difficult to pull off, the mere possibility of such a breach of a sandbox wall implies that ILs, in and of themselves, do not define security boundaries. What’s a security boundary? It’s a wall through which code and data can’t pass without the authorization of a security policy. User accounts running in separate sessions are separated by a Windows security boundary, for example. One user should not be able to read or modify the data of another user, nor be able to cause other users to execute code, without the permission of the other user. If for some reason it was possible to bypass security policy, it would mean that there was a security bug in Windows (or third-party code that allows it).
It should be clear then, that neither UAC elevations nor Protected Mode IE define new Windows security boundaries. Microsoft has been communicating this but I want to make sure that the point is clearly heard. Further, as Jim Allchin pointed out in his blog post Security Features vs Convenience, Vista makes tradeoffs between security and convenience, and both UAC and Protected Mode IE have design choices that required paths to be opened in the IL wall for application compatibility and ease of use.
Not requiring a user to type Ctrl+Alt+Delete to verify that the credential dialog UAC presents for an OTS elevation is one example of security balanced against usability, but there are others, like the ones I describe in my TechEd/ITForum talk User Account Control Internals and Impact on Malware (Jim’s post describes some of the ways you can enhance security while tipping the balance against ease of use, like configuring Windows to require Ctrl+Al+Delete for the credential dialog). For instance, having your elevated AAM processes run in the same account as your other processes gives you the convenience of allowing your elevated processes access to your account’s code and data, but at the same time allows your non-elevated processes to modify that same code and data to potentially cause an elevated process to load arbitrary code.
Because elevations and ILs don’t define a security boundary, potential avenues of attack , regardless of ease or scope, are not security bugs. So if you aren’t guaranteed that your elevated processes aren’t susceptible to compromise by those running at a lower IL, why did Windows Vista go to the trouble of introducing elevations and ILs? To get us to a world where 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 the way we have on previous versions of Windows: with administrative rights all the time. Protected Mode IE and PsExec’s -l option simply take advantage of ILs to create a sandbox around malware that gets past other security defenses. The elevation and Protected Mode IE sandboxes might have potential avenues of attack , but they’re better than no sandbox at all. If you value security over any convenience you can, of course, leverage the security boundary of separate user accounts by running as standard user all the time and switching to dedicated accounts for unsafe browsing and administrative activities.
Look for my in-depth article on UAC internals in the June issue of TechNet Magazine, and if you want if you want to learn about other changes in Windows Vista then check out the first of my three-part Inside the Vista Kernel article series in the February issue of TechNet Magazine.
Comments
Anonymous
February 12, 2007
The following Sysinternals utility has been updated: PSExec v1.80 Update : This update to PsExec enhancesAnonymous
February 12, 2007
I believe DropMyRights will actually add a token to deny administrator rights ... http://msdn2.microsoft.com/en-us/library/ms972827.aspxAnonymous
February 12, 2007
Hoy en cosas interesantes: Live Search para windows Mobile, WSUS 3.0 Release Candidate!!!!!!, MobilesAnonymous
February 12, 2007
Last week at the RSA conference, I had the excellent opportunity to talk to a lot of people about securityAnonymous
February 12, 2007
Reading some security related RSS feeds, I've came upon an interesting article about the new Vista securityAnonymous
February 13, 2007
Well, a lot of time when I talk to people about Windows Vista, two things pop up: User Account ControlAnonymous
February 13, 2007
Seems that UAC isn't sitting well with zdnet blog... http://blogs.zdnet.com/security/?p=29Anonymous
February 13, 2007
The comment has been removedAnonymous
February 13, 2007
PingBack from http://invista.wordpress.com/2007/02/13/russinovich-parla-di-uac/Anonymous
February 13, 2007
The comment has been removedAnonymous
February 13, 2007
Thanks for an excellent post. Please keep blogging often..Anonymous
February 14, 2007
PingBack from http://www.itwriting.com/blog/?p=128Anonymous
February 14, 2007
PingBack from http://aoizora.org/nobue/?p=26Anonymous
February 14, 2007
My main reason for not using UAC is the fact that IE7 needs new windows when crossing security boundaries, i.e. switching from a local site to my webmail and to a non-trusted site causes new instances of IE7, and i am unable to open them in tabsAnonymous
February 14, 2007
As always an excellant read. Reminds me of the Unix/Linux SUDO command. I guess I'll be happy as long as Mac commericals don't confuse users as to the advantages of the new security model and software developers learn how to right software and installations for limited users.Anonymous
February 14, 2007
It's too bad that Microsoft has had to expend so much time and energy creating such a framework... just because so many idiots want to create "malware" that can take over computers and send out spam for penny stocks and "growth" pills. This time and energy could be better spent elsewhere. If only everyone were honest...Anonymous
February 14, 2007
While I applaud the intent of UAC, I do have one substantial problem with it. I have always run as a standard non-privileged user and have used RunAs to elevate applications with an admin account that I use only for that purpose. In Vista I now have to choose to always be prompted for credentials (annoying and time consuming) or just receive the Consent prompt, which of course does not give me the ability to choose when I want to run with local admin creds for local activities vs. a network admin account for domain management functions. I would like to be able to set Consent as the default and have the ability to specify applications for which I would be prompted for credentials.Anonymous
February 14, 2007
PingBack from http://stuart.amanzi.co.nz/2007/02/15/vistas-false-sense-of-security/Anonymous
February 14, 2007
PingBack from http://juergentreml.online.de/techblog/archive/20Anonymous
February 14, 2007
It looks like UAC in Vista is coming under more and more scrutiny. I've seen a lot of links to this post which...Anonymous
February 15, 2007
PingBack from http://gadgetgui.de/blog/?p=571Anonymous
February 15, 2007
PingBack from http://blog.tech-network.de/?p=153Anonymous
February 15, 2007
PingBack from http://www.computerhilfen.com/technews/2007/02/15/vista-security-worse-than-thought/Anonymous
February 15, 2007
PingBack from http://www.jasonmacpherson.com/?p=20Anonymous
February 15, 2007
PingBack from http://blogs.owasp.org/diniscruz/2007/02/15/uac-not-a-security-feature/Anonymous
February 15, 2007
http://msmvps.com/blogs/thenakedmvp/archive/2007/02/15/user-account-control-uac-on-vista-a-useless-feature-t.aspxAnonymous
February 16, 2007
Ciao a tutti. Dopo qualche giorno passato a Seattle ad imparare cose nuove ritorno per segnalarvi alcuniAnonymous
February 16, 2007
PingBack from http://www.telmon.org/?p=124Anonymous
February 17, 2007
The comment has been removedAnonymous
February 18, 2007
PingBack from http://blog.unlugarenelmundo.es/2007/02/18/retazos-de-la-semana-y-xii/Anonymous
February 18, 2007
PingBack from http://www.sahw.com/wp/archivos/2007/02/18/a-vueltas-con-la-seguridad-de-windows-vista/Anonymous
February 19, 2007
PingBack from http://security-samizdat.com/2007/02/19/rutkowska-vs-russinovich-on-vista-uac-security/Anonymous
February 19, 2007
Temat jest prosty(?) Vista, UAC i opinia o nim przedstawiona przez Joannę Rutkowską. A teraz do rzeczy. Najpierw oczywiście mrożący krew w żyłach artykuł o sporze Microsoftu i Joanny Rutkowskiej. Swoją drogą zjeżyło mnie tłumaczenie pojęciaAnonymous
February 19, 2007
You say, "The elevation and Protected Mode IE sandboxes might have potential avenues of attack , but they’re better than no sandbox at all." I couldn't disagree with you more. Weak or easily circumvented security is far worse than no security at all. Why? Because it crease a sense of security when there is no justification for one, aka a false sense of security.Anonymous
February 19, 2007
PingBack from http://blog.imagestr.com/?p=29Anonymous
February 20, 2007
An Example of Why UAC Prompts in Vista Can’t Always Be Trusted People who have been following the notAnonymous
February 20, 2007
PingBack from http://www.liquidmatrix.org/blog/2007/02/20/vista-security-overhaul-questioned/Anonymous
February 20, 2007
The press has been having a field day with headlines like this one due to a recent post by Mark RussinovichAnonymous
February 21, 2007
Devo confessarvi un personale dissidio interno: sotto la corteccia da ingegnere che mi ritrovo, pulsa un cuore da (mancato) teorico di fisica nucleare. Proprio così: da liceale sognavo di avviarmi alla carriera dello "scienziato", grazie ad una illuminazioneAnonymous
February 22, 2007
The comment has been removedAnonymous
February 22, 2007
"Fronteira de segurança" (ou security boundary ) é alguma barreira pela qual código ou acesso não podemAnonymous
February 22, 2007
The press has been having a field day with headlines like this one due to a recent post by Mark RussinovichAnonymous
February 23, 2007
The comment has been removedAnonymous
February 26, 2007
PingBack from http://www.w2k.pl/uac-lubiany-uac-znienawidzony/Anonymous
February 28, 2007
Vista is certainly a step in the right direction (of least privilege computing). Now, when will we finally arrive at a state where administrator privileges are exactly that – there to administer OS level files and processes and ALL users (developers, casual users, guests, etc.) can run on the machine and do everything they need to do WITHOUT requiring any administrator privileges. To be specific, there should for example be an elevated permission level allowing for debugging user space processes that is short of being an administrator level privilege that has jurisdiction over OS level files and processes.Anonymous
March 01, 2007
This is very interesting, but I feel some points could be clarified. "elevations and ILs don’t define a security boundary" Wouldn't it be even better to have created new security boundaries? Isn't it possible to create some kind of trusted path for user input that would prevent hostile processes from sending messages to elevated processes without impairing usability? Which one is the right answer:
- There is a fundamental reason that makes such a trusted path impossible, or at least very difficult to implement within the current Windows security infrastructure. (Can you explain why?)
- There is a fundamental reason why usability would be degraded. (Do you have a precise scenario that show this fundamental reason?)
- It could be done, but it affects backward compatibility so strongly that it was rejected (e.g. because accessibility tools would have to be rewritten).
- It could be done, but it requires so much checking (e.g. validating input for any program that could run elevated, for the example you describe) that you didn't include it in your threat model.
Anonymous
March 02, 2007
The comment has been removedAnonymous
March 02, 2007
PingBack from http://www.errorforum.com/microsoft-windows-vista-error/10998-vista-open-user-privilege-bug.html#post13669Anonymous
March 02, 2007
PingBack from http://www.winboard.org/forum/news/55179-eeye-meldet-sicherheits-luecke-windows-vista.html#post403772Anonymous
March 05, 2007
UAC may not achieve a great deal of security directly but it may still be worthwhile - depending on how the community reacts to it. If developers can get away with "to use our software, turn UAC off" then it won't help. If users won't accept that, developers will be forced to write software that doesn't assume admin privilege. That would be a big step forwards.Anonymous
March 06, 2007
PingBack from http://www.accountmerchant.org/psexec-user-account-control-and-security-boundaries/Anonymous
March 07, 2007
PingBack from http://www.itwriting.com/blog/?p=151Anonymous
March 07, 2007
PingBack from http://quotes-manager.com/blog/2007/03/07/i-did-it-true-uac-for-vista-and-xp-by-safezilla/Anonymous
March 10, 2007
The comment has been removedAnonymous
March 12, 2007
There's a fundamental problem here that's not going to go away soon: the Windows security model has become extremely complex. It's hard to program, which is what leads to such unforgiveable consequences as Grisoft making their files world-writable ("I can't get the SID-lookup to work on all platforms" "Well just add the Everyone group then - that's easy enough and it's sure to work everywhere") It's hard to identify why apps fail when running with limited rights, even with Mark's tools (and where would we be without those - thanks so much, Mark) which is what leads to developers running as admin, and to corporate support staff setting up users as local admins on their workstations. No doubt also that's why the default user is still being created as an admin when Windows is installed. Nor are matters helped by friendly error messages that hide the true cause of a problem, which admittedly in many cases is not even available to the failing application. How often have you had a COM object fail with a 0x....0005 error and cursed for not knowing to what object access was being denied? The more complicated the security model, the harder it is going to be to persuade anybody - developers, installers, or (heaven forbid) end users - to abide by it. Additional complexity in a security system helps nobody except those with the time and incentive to find ways of breaking it. Worse yet: it increases their chances of doing so. Sadly, the addition of Integrity Level is likely only to exacerbate this situation.Anonymous
March 12, 2007
UAC is already helping: http://www.cakewalk.com/support/kb/kb20070117.asp (I don't know what this product does, but it didn't used to run without administrator access and now it does - because of UAC.)Anonymous
March 16, 2007
I can't imagine that this will make the front page of People Magazine , but if you are a Network or SecurityAnonymous
March 25, 2007
What is Vista's User Account Control as described by the Uber Geek crowd: http://blogs.technet.com/markrussinovich/archive/2007/02/12/638372.aspxAnonymous
March 26, 2007
The comment has been removedAnonymous
April 09, 2007
The comment has been removedAnonymous
April 18, 2007
PingBack from http://blog.afaceri-pe-internet.com/00200712/vista-security-model-%e2%80%93-a-big-jokeAnonymous
May 22, 2007
PingBack from http://blogs.zdnet.com/security/?p=29Anonymous
June 10, 2007
Mark, A thought: How hard would it be to write a piece of code that can invade the sandbox and then lie in wait until an elevation of priviledge occurs? Also, does a program at medium mode have acces to the file that it was run from, that is, would IE have access to iexplorer.exe? Sounded like a "no". I'd love to see your thoughts on both these items.Anonymous
June 20, 2007
The comment has been removedAnonymous
June 25, 2007
The comment has been removedAnonymous
July 04, 2007
Microsoft has made it fairly easy to get elevated from a limited user, via Manifest or RunAs verb to ShellExecute, but I have noticed a distinct lack of ability to spawn a limited process from an elevated one. Now, I can use CreateRestrictedToken and CreateProcessAsUser to create a restricted process, a la the "run as limited" option in process explorer. But I have found that processes created in this way (including from the process explorer option) have odd "access denied" errors running things like whoami /all. These seem to be fixed in psexec -l. Can you explain what code was required to make that work right? Also, can you explain how to set the integrity level of the process, as I would like to create a process in Medium level since this is what normal limited processes are. I was trying to track though psexec -l in a debugger with the interesting function calls, and see that you call SetTokenInformation with TokenLinkedToken class. I cannot seem to get this to work, I get that I do not have a required privilege. And looking at the memory for the TOKEN_LINKED_TOKEN struct in the debugger, your token looks more like a valid pointer than any of the token handles I have been seeing. Is there some trick to this? I may have to dig into the kernel debugger to see what is going on with these...Anonymous
July 04, 2007
The comment has been removedAnonymous
July 04, 2007
Figured out my questions on my own: turns out the call I thought was setting the linked token was actually setting something else (probably was the integrity level). Setting the linked token requires SeCreateTokenPrivilege. The fix which makes the whoami command start working is to add the user of the token to the token's default dacl with PROCESS_ALL_ACCESS. Setting the integrity level is done with SetTokenInformation with the TokenIntegrityLevel option, and specifying the proper integrity level Sid. I wish there was a way to set the Linked Token and the other elevation-related properties of the token, so that code which is inspecting these properties to see if it is elevated can properly tell that it is not. Any ideas?Anonymous
July 06, 2007
PingBack from http://doubt.pernick.org/2007/07/06/WindowsSecurityBoundaries.aspxAnonymous
August 02, 2007
Where can I locate the Default setting for the UAC policies on all Vista editions other than Home & Enterprise for these: 1.User Account Control: Detect application installations and prompt for elevation Default: Enabled (home) / Disabled (enterprise) 2.User Account Control: Behavior of the elevation prompt for standard users Default: Prompt for credentials (home) / Automatically deny elevation requests (enterprise) The above defaults are documented on the Explain Tab of the Properties Tab of each of these policies - but are INCOMPLETEAnonymous
November 14, 2007
I am finding the difference between AAM and OTS less than clear. Is the article indicating that OTS leads to a security boundary due to the elevated process being launched under a separate user account i.e. the admin, or is this merely terminology to indicate which account the elevation request came from?Anonymous
December 08, 2007
Thank goodness I finally came across your site. Basically, I know barely computer basics, and I don't even know how to use the command promt, but even someone as unknowledeable about computers such as myself knows that something is amiss when the hierarchy in my folders looks all messed up- I was begining to think that all this strangeness is just a figment of my imagination - My computer is acting strangely- active desktop, remote console, default user, owner, shared files, sharing files, Local C and C??? It seems as if someone is controlling my pc remotely from the console. I have learned a great deal about computers over the past few weeks just trying to unravel the fact that I am not imagining things, but a novice like me needs a lot of help fixing things.Anonymous
April 09, 2008
Cool guestbook, interesting information... Keep it UP. excellent site i really like your stuff.Anonymous
June 28, 2008
I am finding the difference between AAM and OTS less than clear. Is the article indicating that OTS leads to a security boundary due to the elevated process being launched under a separate user account i.e. the admin, or is this merely terminology to indicate which account the elevation request came from.Anonymous
June 30, 2008
The comment has been removedAnonymous
October 28, 2008
This is great. Now my 75 year old mum can use her PC securely... right after she studies for her MCSE... Are you really sure you guys can't make things easier?Anonymous
February 25, 2010
How hard would it be to write a piece of code that can invade the sandbox and then lie in wait until an elevation of priviledge occurs? Also, does a program at medium mode have acces to the file that it was run from, that is, would IE have access to iexplorer.exe?