How come the technique for launching an unelevated process from an elevated process doesn’t work?


A customer was following the Execute in Explorer sample to launch an unelevated process from an elevated process. (A sample which I rehashed some time ago.) The customer reported that the resulting process was still elevated.

Upon closer inspection, the customer had disabled User Account Control (UAC).

If UAC is disabled, then the ability for an administrative user to launch an unelevated process no longer exists.

Since people like tables, here are some tables.

In the classical world without UAC, administrators are administrators, and standard users are standard users. In other words, processes run by administrators are always elevated, and processes run by standard users are always non-elevated.

UAC disabled
User type Process type
Elevated Non-elevated
Administrator
Standard

UAC added a new option to the table: The administrator who voluntarily relinquishes administrative privilege and runs a process non-elevated.

UAC enabled
User type Process type
Elevated Non-elevated
Administrator
Standard

In words: In the classic non-UAC world, an administrative user can run processes elevated, and a standard user can run processes un-elevated. If UAC is enabled, then a new combination becomes available: An administrative user can run a process non-elevated.

If you disable UAC, then you are back in the classic world, where there is no such thing as an administrative user running a non-elevated process. It's therefore no surprise that when you try to run the process unelevated, it still runs elevated.

You can look at this issue another way: If UAC is disabled, then Explorer runs elevated. And therefore, if you ask Explorer to run a process, that process runs elevated too.

It turns out that the customer turned off UAC because they didn't want to see any UAC prompts; they wanted their program to elevate silently, yet launch child processes unelevated. From a security-theoretical point of view, this is not an interesting configuration: If you allow silent elevation, then those child processes can just silently elevate themselves, and your attempt to run them unelevated accomplished nothing.

If you disable UAC, then the only way to get both elevated processes and unelevated processes is to run the elevated processes as one user (an administrator) and the unelevated processes as another user (a standard user).

Comments (40)
  1. anonymouscommenter says:

    Called it from just seeing the title.

  2. anonymouscommenter says:

    At the risk of starting another fight, silent elevation is what you get if you try to turn off UAC in W8. Really turning it off is possible but non-ovbious. For the one box I had to run that way I had to call MS for activation as the normal routine didn't work.

    I suppose one could force non-elevated from elevated by making the reduced token (change Administrators group to deny only …)

  3. anonymouscommenter says:

    So, to translate this into Unix terms, if you turn off sudo, the real and saved uid/gid tokens vanish, leaving only the effective uid.

    Wait, that doesn't make sense.  I guess this one just doesn't translate, since Unix and Windows have entirely different security models.

  4. anonymouscommenter says:

    This was a very interesting and helpful article, Raymond. Your explanation, especially with the tables, was very clear and interesting. Thanks!

  5. anonymouscommenter says:

    And if you eliminated the ability to disable UAC entirely, this problem would vanish.

    It would be replaced by other problems, all of which could be solved by saying "Company X just makes insecure crap, you should try another company."

  6. Antonio 'Grijan' says:

    @Anon: the problem is not with *unsecure* programs. No. the real problem are *legacy* programs designed for previous versions of Windows with no security (95/98/Me) or that everybody outside corporate environments ran always as administrator (NT/2000/XP). UAC does its best to allow those legacy programs to work, but it's at least reasonable not having to dismiss an elevation dialog on a tool you launch fifty times a day. I'm not saying it's a good idea – I'm saying that, in those cases, the users may have a point.

  7. Anon: Unfortunately "Company X makes $(whatever-type) crap" rarely goes down well with customers.  Especially if you're Microsoft; then they just see it as Microsoft being crap and blaming someone else.  The fact that you're shifting the blame to where it belongs doesn't matter.

  8. anonymouscommenter says:

    What I'm still not clear about: Is UAC a "security feature" now or not?

    Obviously, from a security standpoint I shouldn't run as an administrator/root. Under Unix, you just run as a standard user and su(do) on an as-needed basis. In older windows versions, almost everybody ran as administrator, even though it's inadvisable, because too many programs misbehaved. But they really should have run as a standard user.

    But what's the situation now? Should I run as a standard user, now that UAC forced programs to behave better, or is it ok to run as a non-elevated administrator and rely on UAC to separate privileges. I'm asking this because there seems to be different opinions if bugs that allow administrators to elevate without interaction count as "local privilege escalation" or as non-security bugs, because "UAC is not a security feature".

  9. anonymouscommenter says:

    "If UAC is disabled, then the ability for an administrative user to launch an unelevated process no longer exists."

    Of course this ability exists: RUNAS.EXE /TrustLevel:"standard user" <command line>

    resp. its equivalent using

    SaferCreateLevel(SAFER_SCOPEID_USER, SAFER_LEVELID_NORMALUSER, 0L, &saferlevel, NULL)

    SaferComputeTokenFromLevel(saferlevel, NULL, &token, 0L, NULL) and finally

    CreateProcessAsUser(token, …

  10. anonymouscommenter says:

    Was this reported as "I found a security vulnerability!"? :)

  11. anonymouscommenter says:

    @AC: The whole class of bugs that was reported as the cryptbase.dll hole will never be fixed. Ergo, no real security benefit for UAC unless set to the highest level (that almost noone can tolerate). Which is why I say screw it.

  12. Nacimota says:

    It seems really silly to me that people justify turning off UAC by saying elevation prompts inconvenience them, but are apparently willing to suffer countless other inconveniences as a direct result of making that change. Modern apps no longer working is probably the one I hear about the most.

    It boggles my mind that people (power users especially) are still so resistant to UAC.

  13. IanBoyd says:

    @Joshua You disabled UAC completely, rather than setting it to "Always Prompt", because the default setting is not "Always Prompt"? Why not set it to the secure "Always Prompt", since you were already there?

    Postscript: You can find source code, and a sample application, that demonstrates how to silently elevate to an administrator [here](http://www.pretentiousname.com/…/win7_uac_whitelist2.html). It only works when you are an administrator running as a standard user, and you're running UAC at the default setting, on Windows 7 or later.

    Windows Vista was not susceptible to the issue, as it did not have a white-list. You can close the vulnerability by setting UAC to the highest setting ("Always Prompt"). This will return you to the default Windows Vista-style behavior. [Mark Russinovich also talked about the Windows 7 UAC vulnerability](technet.microsoft.com/…/2009.07.uac.aspx) in a Technet article.

  14. anonymouscommenter says:

    @IanBoyd: It's not about me. It never was. It's about grandma. She hasn't got a clue. I will care when a solution that isn't trivially bypassed is tolerable to most users.

  15. anonymouscommenter says:

    …and once again a UAC blog post leads to flame wars in the comments.

    Getting tired of it yet, Raymond?

  16. Darran Rowe says:

    @Joshua:

    The problem I actually feel is here isn't about grandma or anything, but you seem to be against UAC.

    The thing to remember about the UAC settings is that those ways to get around UAC when it isn't set to maximum should actually be a non-issue, this is because that setting was introduced with a huge * next to it. The UAC settings page quite clearly says "Recommended if you use familiar applications and visit familiar websites."

    The intended use case for this is the "regular user" like your grandma. The user who is only interested in checking emails and watching funny cat videos. In fact, for that kind of regular user, I would even go as far as not even giving the user account any kind of administrative rights at all, just create it as a limited user and all of these issues go away. For the people that I have installed Windows for and set up like this, I have yet to hear any kind of complaint.

    If there is a need to regularly run an application which prompts, there is a better way. It involves using a service to do the elevation. In general though, disabling UAC is not needed IMO.

  17. anonymouscommenter says:

    I don't know, I've habitually run with UAC maxed, and it hasn't given me hives or cancer or whatever it is that makes people insist they have to turn it off.

  18. anonymouscommenter says:

    @Kevin:  I'd hardly call these comments a flame war.  "Mildly heated discussion on a cool afternoon" would be more accurate.

    UAC represents, for better or worse, a pretty fundamental shift in Windows' security paradigm.  It's also highly visible and was implemented as a series of technical and security tradeoffs.  All that adds up to a topic bound to drive discussion.

    Thanks for the post, Raymond.  However, I actually don't like tables — can you please represent these thing using formal set notation instead?  Thanks! :)

  19. jon says:

    The UAC whitelist hole is a nice example of being on the *wrong* side of the airtight hatch and still being able to escape.

  20. anonymouscommenter says:

    I like UAC.  It is the equivalent of sudo in UNIX.  If the prompt appears I can make a decision to back out of it, especially if I didn't expect it to be the case (use to happen when I browsed the web but web browsers have gotten so much better at sandboxing activity).

    My account is not an administrative account, so UAC is great for letting me know that I'm doing something that requires more privileges.  As a developer I try to reduce the number of items that require elevation to as minimal as possible, so that other people don't require administrative privilege to use what I develop.  Seems like other developers don't care and have no problem writing everything to require your account to run as an administrator.  I wonder if these are the same developers that run around touting how superior Linux security is (when the reality is that they have poor habits on Windows).

  21. anonymouscommenter says:

    UAC whitelisting was DEMANDED by the same people complaining about UAC whitelisting.

  22. anonymouscommenter says:

    @Nicholas: No it is not. That's an incredibly important thing to understand: UAC is NOT a security boundary. If you tell Microsoft about a way to get around UAC they won't consider it a security flaw. The reason we got UAC was to force developers to get their act together and to stop writing software that made bad assumptions.

    Here, there's Larry Osterman amongst many others (I'm sure Raymond made it too in the past) summarizing this very succinctly: channel9.msdn.com/…/773c9d79f8df4fa8bc489deb00e05c3d

  23. anonymouscommenter says:

    @Antonio 'Grijan' All versions of NT had the same security. Win95 and 98 had similar security standards.

    Terrible programmers never followed instructions, which is why Microsoft decided to beat them with the standards.

    Unfortunately, the devs cowered and said "We're sorry," which of course convinced MS to back down completely and give them a nigh-infinite number of loopholes, including the part where they simply tell customers to disable all the security features built into the OS.

    We wonder why things aren't secure, then we NEVER enforce even the most basic level of security. I don't know why anyone bothers.

  24. hacksoncode says:

    @AC: "What I'm still not clear about: Is UAC a "security feature" now or not?"

    Personally, I would consider it more of a convenience feature than a security feature.

    I mean, you could always have run as a standard user all the time. It's just a huge hassle if you ever have to do something that modifies the system.

    But running as admin all the time makes it very easy to accidentally do something that you didn't intend (or for some app to do it without you knowing).

    So you run as admin, with all the security holes that implies, but you are asked to do things that people commonly accidentally do.

    Or you run as a standard user, and if you have to do something elevated you can enter an admin's credentials for just that task.

    It's not ideal, but it's definitely more about convenience that security.

  25. CSharp Fan says:

    I have a machine that has Windows 8 with UAC disabled,  yet still when I launch cmd I don't get 'Administrator' in the title,  for that I need to do right-mouse, launch as Administrator, same issue with Visual Studio, if I don't run as Administrator I can't connect to IIS.

  26. anonymouscommenter says:

    @CSharp Fan

    Turn UAC on.

    Problem solved.

  27. anonymouscommenter says:

    @voo: Very interesting link.  However, what are you trying to say?  If UAC prompts me and I click "No" the action can happen anyway?  If not then what do you call that if you don't call it security?  At minimum it has to be some level of protection.

  28. anonymouscommenter says:

    @Darran Rowe: Oh no you don't I'm not going to get backed into that flamewar.

    UAC as the UI presents itself to be is a good idea. UAC as actually implemented needs serious work and isn't getting it.

  29. cheong00 says:

    @Stefan Kanthak: About to post something similar. I remember Process Explorer in has option to "run as standard user" in the days of WinXP too, where UAC obviously is not there.

    I didn't know the programatic way to do it, although it's not difficult to find out in search engine either.

  30. anonymouscommenter says:

    @Nicholas A security feature may not be circumvented by a malicious program, a normal feature doesn't have this requirement. So it's just like the "do you really rant to delete this file?" dialog – it can stop you from accidentally doing something, but if someone wants to delete the file it won't stop them

  31. Darran Rowe says:

    @Joshua:

    Flame war? I apologise if it came across as that.

    All I meant to do was to give counter examples as to how working with UAC on works very well for those of limited technical experience.

    Well, I have no intention of taking this any further.

  32. anonymouscommenter says:

    Clearly, half of you have no clue what UAC is actually for.

  33. John Ludlow says:

    @Nick:

    I think the confusion came from a comparison of UAC vs sudo, which turned into "UAC != Security".

    I think UAC is like sudo, which implies that sudo is not a security feature because it's like UAC. In other words, the following statements cannot all be true:

    1. sudo == security

    2. UAC != security

    3. UAC == sudo

    At least one of these statements is false, and I'd like to know which one. I'm inclined to believe it's the first one. The impression I get from the above fla- (ahem) "discussion" is that many people believe it's the 3rd one. I'd be interested to know more about that.

    Discuss, in a non-fire-based manner.

    (Yeah, I know, this is the internet so I may as well have asked for gnomes and unicorns).

  34. John Ludlow says:

    BTW, I realised half a second after posting that that it reads like it's totally directed at Nick and I'm accusing him of flaming. That was not my intention. The first paragraph was in response to Nick's post.

    The rest was not specifically directed at Nick.

    Apologies. I'll just go hide in a corner now.

  35. voo says:

    @John Ludlow: There's been only a single argument about sudo not being a security feature and that was by one person who already admitted to not knowing that UAC wasn't a security feature.

    But yes, if you need clarification: UAC is not a security feature because MS doesn't consider it one (there are lots of ways to circumvent it in the wild which are accepted as wont-fix by MS), while sudo *is* one because any privilege escalation you manage to find in it will definitely get a whole lot of attention and get fixed.

    So the wrong statement there is #3, very simple.

  36. anonymouscommenter says:

    Convenience and security are often at odds. There's plenty of users who think password prompts are inconvenient and would love to be able to turn them off if the option existed…but if they could, would we join them in complaining about those mean old passwords or would we laugh in their face when their account gets hijacked and used towards malicious ends? UAC is often annoying, but it was a case of Microsoft deciding to throw up "This application is dumb and insecure and wants to do dumb insecure things" messages in an attempt to force applications to behave better, just like so many of us have always dreamed of. Instead, though, the vendors simply ignored it entirely and let the obnoxious behavior stand, and instead of complaining about the software companies continuing to behave badly even when it hurts users, we just complain about Microsoft bothering us with all those popups about poor application behavior when we're just trying to get something done!

  37. anonymouscommenter says:

    @John Ludlow

    People frequently say that UAC isn't a security boundary, which is true.

    Many of them also imply that UAC isn't a security feature, which is false. UAC combines multiple security features in order to present a secure dialog so that you can approve a request for higher permissions. That's a lot of security components for it to not be involved in securing the machine.

    sudo is similarly not a security boundary, and similarly combines security features. However, they don't work on the same principles.

    Aside: if a Microsoft Representative wants to make an official statement regarding UAC not being any sort of security feature, in their official capacity, with the full force of official policy at Microsoft, in an authoritative medium, great.

    Otherwise, forum posts and blogs aren't official statements, they aren't official documentation. If they were, this blog would have a lot less informative posts.

  38. anonymouscommenter says:

    Second aside:

    NTLM has been trivially-vulnerable since the dawn of time.

    Who wants to make the statement that NTLM isn't a security feature because it has unpatched vulnerabilities?

    The presence of a method to bypass a security feature doesn't make a security feature not a security feature. It only makes it insecure.

  39. anonymouscommenter says:

    Microsoft promoted UAC as a security feature until they got scared by all the negative press Vista got because Explorer's implementation of UAC was so terrible. Therefore, it's not a security feature any more.

    (of course fixing Explorer was never on the cards)

  40. anonymouscommenter says:

    @Anon True about NTLM. What does stop making something a security feature is if the vendor explicitly states that they don't consider it such.

    Take for example the SHA256 hash in git. Does it have security implications? Yes, actually quite strong ones. But is it a security feature? No, because the git developers don't consider it as such.

Comments are closed.

Skip to main content