UAC, UAC, go away, come again some other day

committed to database on June 10, 2009 at 6:46 pm Eastern Standard Time 52 comments digg this

w7uacshield I was reading Mark Russinovich’s latest UAC article and Long Zheng’s latest scribblings and… developed quite the headache. Honestly, I’m tired of trying to sort out what UAC really is and don’t care anymore. UAC has become this gigantic undocumented blob of an idea that is explained (differently) on-demand every single time, to fit some marketing agenda du jour, and I’m sick of it. Mark jumps up and down about how UAC isn’t a security boundary and how we’re stupid for thinking such, yet Microsoft’s own sites pitch otherwise. Whatever, guys.

Here’s my million dollar question: If UAC wasn’t designed to ultimately protect us from anything, why does its icon resemble a damn shield?

  1. Tim Foote June 10, 2009 at 7:10 pm

    I would just like to say that UAC is a pain in my ass and it’s the first thing I disable when installing Vista or 7.

    I think they should change the shield icon to a demonic troll or something of the sort as that’s the way it behaves on a good day!

  2. Dan June 10, 2009 at 7:17 pm

    Maybe they’re trying to protect the system from the user. :)

  3. Brad June 10, 2009 at 7:32 pm

    So should we just not use UAC then?

  4. Leo Davidson June 10, 2009 at 8:18 pm

    http://blogs.msdn.com/uac/

    “User Account Control (UAC) is a core security feature in the next release of Windows Vista and Windows Server code name Longhorn.”

    https://blogs.technet.com/jesper_johansson/archive/2006/06/22/438316.aspx

    “Once the OS is released, if you absolutely can’t stand a security feature that is designed to protect you, by all means, turn it off”

    etc.

    Mark Russinovich has been more consistent, I think, but I used to get the impression he was saying that UAC was a security feature that wasn’t as good as an actual security boundary but was better than nothing and tried its best. Now it seems we’re (sometimes) told it isn’t even a security feature. UAC is for convenience and annoyance, or something. The convenience of being annoyed for no reason.

    But at other times — in fact most of the time — we’re told it is a security feature, and most users are going to think it is one because it looks and smells like one and it’s marketed as one.

    Whatever… I can’t believe that MS honestly think we’re all going to switch to standard user accounts when using them is more annoying than admin accounts in Vista, which MS know were too annoying for too many people to use. If MS are serious about standard user accounts being the goal then they have a lot of work to do, particularly in making Explorer and the Control Panels show fewer prompts. Instead MS have made admin accounts more tempting with Win7, not less. Fail.

    http://www.techsphere.org/wordpress/2007/05/08/microsoft-withdraws-vista-security-claims/

    “Russinovich’s talk was supposed to give professionals an idea of how to work with UAC in order to avoid excessive pop-up warnings and avoiding breaking the UAC model.”

    ^^^ I think Mark should’ve given that talk internally! Clearly the Explorer/shell team missed the memo as their code produces excessive pop-ups and required Microsoft to break the UAC model in Windows 7 as a workaround which nobody else is allowed to use. Utter fail.

  5. Dominik June 10, 2009 at 8:33 pm

    “…why does its icon resemble a damn shield?”

    lol

  6. Mopeto June 10, 2009 at 11:29 pm

    I lol at people who, argue “That thing is fucking anoying, is horrible, etc etc” but then they got fucking malware, virus, etc and blame microsoft on poor security, damn.
    I only use Common Sense 95 and even not antivirus and I don´t get fucking plague.

  7. Mattisdada June 11, 2009 at 12:02 am

    I agree with what Mopeto is saying, although fairly badly said.

    As long as you use some good old fashion sense, you will be RELATIVELY safe. If you only download from trusted sources, have a firewall of some sort (hardware, or software). You will be pretty safe.

    If you say, go to lots of warez pr0zn sites and the such. You will easily get allot of malware on your computer.

    The problem is allot of, novice, users do stupid things. Windows needs to be more idiot proof.

    For example, 99% of novices, NEVER read what a popup is, they just press a button (a random button). And i do believe that UAC makes this worse. The biggest threat is the dumb user, not outside entities generally. And the dumb user will let IN the outside entities.

    I do believe Microsoft needs to keep this in mind. “Power” users are generally fine. If we DID get malware, it does less damage, and we can quickly neutralize it to some extent without an AV even.

  8. Resle June 11, 2009 at 12:39 am

    > If UAC wasn’t designed to ultimately protect us from anything, why does its icon resemble a damn shield?

    It’s not a shield: http://image55.webshots.com/55/4/80/17/545248017SNMPdt_ph.jpg

  9. Jody June 11, 2009 at 12:45 am

    As they say in other places this auto-elevation (and code injection) is only a problem if you are running in an Administrator account. Run as a standard user and none of this is a problem, you will always be prompted for elevation.

  10. pin June 11, 2009 at 1:32 am

    in fact in Win7 they changed the colour like to say now it protects less than Vista.

  11. Leo Davidson June 11, 2009 at 3:17 am

    @Jody:

    a) Running as standard user brings pretty much all the UAC prompts that were in Vista back.

    b) On top of that, you have to type a password rather than click a button.

    Microsoft clearly realise that even the button-click prompts were too annoying for many users as that’s why they removed them for admin users (for their badly-written software which prompts too much only).

    You cannot honestly thing that standard user accounts, as they stand today, are a solution that people will actually use after the reaction to Vista’s UAC.

    Additionally, standard user accounts are not the default. You have to go out of your way to use them. Almost nobody will, except in businesses where they were already running locked-down accounts since the days of NT4 and where UAC elevation will barely be used at all.

    Standard user accounts are a distraction and an excuse as far as Windows 7 goes. You might as well say “People should use Linux to be more secure” as it’s about as relevant and likely to happen. If Windows 8 (or whatever) actually makes standard user the default, and makes improves the user experience to one that people might actually put up with, then the argument will hold water.

    The thing is, we’re only arguing about the stupidity (and unfairness on 3rd party developers) of Windows 7’s UAC because of the default settings. People can change to Always Prompt and make it like Vista… Unless we explain why Windows 7’s defaults are the worst of both worlds — annoying prompts for some applications combined with almost zero difficulty in bypassing the prompts for anything that really wants to — and inform people that they can either set UAC to always prompt or to silently elevate (for all apps), people are just going to use the defaults.

    The one thing most people are not going to use in Windows 7 is standard user accounts. It’s more painful than what everyone complained about on Vista, not less.

  12. John Sedlak June 11, 2009 at 3:35 am

    What are you guys doing that requires elevation so much? I always held onto the idea that UAC was there to be a checkpoint whenever software wanted to change the system in some way. Unless I am installing something or moving files into the system directories, I very rarely run into the prompts.

    If anything, I think UAC should get tougher on software. Each process should be run in isolation from everything and when another process wants to come into that space or that process wants to move out, show a prompt with the two processes causing the problem.

  13. Leo Davidson June 11, 2009 at 5:54 am

    I don’t think it’s supposed to resemble a shield (or the firewall icon etc.)…

    The new Windows 7 UAC logo has just been unveiled:

    http://www.pretentiousname.com/misc/uac_comedy_tragedy_security_theatre.png

    :-D

  14. MagicAndre1981 June 11, 2009 at 6:25 am

    Hi Leo, what about releasing a demo app? This will impose pressure upon MS to fix it

  15. Leo Davidson June 11, 2009 at 7:05 am

    I’ve decided not to release the demo app for now (except for a handful of people to verify) because I think it’s more likely MS would just break that particular demo app (which they could do quite easily, e.g. block the exe via Windows Defender) rather than address the underlying issue.

    That’d mean I’d have to waste time making another demo app which proved the hole still existed. I’d rather spend my time on something more constructive (or editing my monstrosity of a webpage :) ).

    I will eventually release it and the source code, just not yet.

    With Windows 7 at RC status and RTM in a few weeks, I can’t see Microsoft changing anything now. They’ve shown no interest in the issue and haven’t responded to offers to give them the full details (which includes another issue that AFAIK hasn’t been talked about in public yet and makes it easier to turn the main “copy a file” thing into “run anything elevated”).

  16. anonymous June 11, 2009 at 7:25 am

    I’m now convinced that the Explorer team is the worst amongst the various Windows teams.

  17. Horseradish June 11, 2009 at 8:17 am

    I’m with Brad. I disable UAC in group policy and use “safe surfing” and other best practices to keep my system secure. UAC has a false security, and I’m more vigilant and respective of security when I don’t rely on anything else to keep me safe.

  18. Marty June 11, 2009 at 9:19 am

    UAC is a security FEATURE, not a security BOUNDARY. That’s a technical term that is more than just semantics.

    Personally I don’t see what the big deal is. What are you doing that requires so much elevation? I can understand disabling UAC while building a system, but after that turn it back on. If you have apps that you always run elevated, setup a scheduled task and run them at startup, or on demand with a shortcut. This has been documented since Vista was in beta. If you do a lot of file system work, create a scheduled task for cmd.exe or powershell.exe to run elevated at startup, and use that for copying/moving/deleting.

    I’ve been using the same desktop system since Vista was in beta, and I don’t even have anti-virus installed. I leave UAC enabled and rarely see a prompt. This system has never had a virus infection, runs fast, no crashes, and only gets rebooted once a month when patches require it. And I’ve never rebuilt it, it was only rebuilt for the final RTM code, rather than upgrading over several beta upgrades.

  19. Sameera June 11, 2009 at 9:30 am

    “why does its icon resemble a damn shield?”

    You know, if you squint a bit and concentrate really hard, you can make out what that symbol really is…

    It’s Steve Ballmer’s right hand giving you the finger…
    :D

  20. Stephen June 11, 2009 at 10:17 am

    That icon isn’t there to represent what UAC is or what it does for the user. It’s there to be found by Link for use against Ganon, protecting the princess and the Iraq and U.S. Americans and everywhere like, such as. DUH, RAFAEL! GET IT RIGHT! UAC FOREVAR! lol.

    -Stephen

  21. Leo Davidson June 11, 2009 at 10:20 am

    @Marty:

    “UAC is a security FEATURE, not a security BOUNDARY. That’s a technical term that is more than just semantics.”

    Microsoft seem to be claiming it isn’t even a security FEATURE anymore. That’s their excuse for creating bigger holes in it instead of closing off the existing holes (which are also used as an excuse: “The old system wasn’t perfect so new flaws don’t matter!”).

    “Personally I don’t see what the big deal is. What are you doing that requires so much elevation?”

    The big deal is that the default Win 7 settings are the stupid combination of prompts for 3rd party software and next to no enforcement of those prompts. The only time you’ll see a prompt is if the app didn’t want to hide one from you, essentially.

    If you don’t see many elevation prompts and don’t mind them then you’re like me and you won’t mind turning the setting up to Always Prompt; the default sucks for you and me because it reduces our security (allowing compromised/malicious medium-level processes to jump to high-level silently and immediately) for no benefit.

    On the other hand, people who do get annoyed by all the prompts will still be annoyed by the ones for third party programs (as well as stuff like the Sysinternals tools).

    People who run standard user accounts but are still the computer’s administrator will continue to be annoyed by lots of UAC prompts where they have to type the password each time, sometimes several times while dealing with the same folder or whatever (unless they use a 3rd party file manager which handles UAC in a nicer way).

    The point isn’t that you can configure things to be as secure as they were; it’s that the new default configuration is completely stupid to anyone who stops and thinks about it. And Microsoft keep moving the goalposts to suit their argument. (e.g. They don’t care that this hole to bypass the prompts exists, yet they refuse to allow a proper system to whitelist third-party code because allowing third-party code to bypass the prompts* would be bad. What the hell kind of logic is that?)

    (*I’m talking about the prompts, not the entire UAC API. Making apps use the API to gain elevation is a good idea. Hassling the user with a prompt which is easy to bypass is a stupid idea.)

  22. richard June 11, 2009 at 2:00 pm

    Leo Davidson, you should post to channel9. There is a thread about this going on, with some MS developers to boot:
    http://channel9.msdn.com/forums/Coffeehouse/473037-UAC-controversy-the-last-episode/

  23. Eldarien June 11, 2009 at 3:32 pm

    “The one thing most people are not going to use in Windows 7 is standard user accounts. It’s more painful than what everyone complained about on Vista, not less.”

    This is absolutly not true in a “more painful” part. I am using limited accounds in XP for a long time (and now in 7), and if in XP you have to run setup.exe as admin manually, 7 will ask you to run as admin — that’s the one and only “painful” part. There are nothing painful in everyday work after all software installed and configured. Also, this is much more secure and I think is the only right way. It just needs a little more work for better user friendlyness.

  24. xaml June 11, 2009 at 7:23 pm

    lol

  25. Leo Davidson June 11, 2009 at 8:53 pm

    @Eldarien: If you were willing to put up with standard user on XP then good for you. Please realise, though, that if everyone else was like you then Microsoft would not have had to change UAC in Windows 7 at all because UAC in Vista would’ve been perceived as absolutely wonderful by everyone.

    It wasn’t.

  26. Leo Davidson June 11, 2009 at 8:57 pm

    …besides which I was comparing Vista/Win7 standard user prompts to Vista admin prompts. They are more painful; how can you deny that? You have to type a password instead of click a button.

    Sure, they are less painful than switching users on XP was, but that’s besides the point. I’m not arguing for UAC to be ditched entirely.

  27. Leo Davidson June 12, 2009 at 9:27 am

    @Myself: “I’ve decided not to release the demo app for now”

    I had a change of heart, after recent discussions with people on all sides of the issue. Source and exes are on my website now. Long has also put up a new article with a video demonstrating it running on the RC build.

  28. Good Job, Leo Davidson & Long Zheng June 12, 2009 at 12:50 pm

    I saw Long’s video: Very well done to explain the overall idea.

    I read Leo’s source-code comments. Helpful, but, Leo, where’s your video to go with it?

    I’m a programmer (VB, etc.), but I have never used C++, as it gives me a headache. Still, I wouldn’t mind a guided video walkthrough of Leo’s code by the master himself.

    GOOD JOB, GUYS!

  29. Leo Davidson June 12, 2009 at 3:25 pm

    “Helpful, but, Leo, where’s your video to go with it?”

    My videos are here: http://www.pretentiousname.com/misc/win7_uac_whitelist2.html#videos

    “Still, I wouldn’t mind a guided video walkthrough of Leo’s code by the master himself.”

    Ah, if you want a video going over the code then there isn’t one, but check out the readme file that comes with the code for a point-by-point description of what it does.

    Everything that the code does uses standard techniques which are well-documented on the web. (e.g. Look up articles in MSDN, CodeProject, etc. on “code injection”.) So there’s nothing really novel going on, except what’s described in the readme.

    If you look at the source code, the interesting stuff is in the *_Inject.cpp file, and a little in the Utils file. Most of the other code is boring GUI stuff that will only bog you down.

  30. el_bot June 12, 2009 at 6:03 pm

    Don’t forget that malwares isn’t the only threat. There are shell codes, remote exploits, etc (take a trip by milw0rm if you disagree). Open a document PDF with a shellcode embedded under XP and you will notice the difference…
    Anyway, in the world Windows, the main threat is the user: every thing that try educates it ,a priori, is fine.

  31. KsbjA June 13, 2009 at 4:16 am

    The right question is not, whether UAC was designed to protect something. It was, undoubtedly. The only question is, if it actually does that.

  32. Leo Davidson June 13, 2009 at 6:39 am

    The source code is now online in HTML format as well. Start here:

    http://www.pretentiousname.com/misc/W7E_Source/Win7Elevate_Inject.cpp. html

    I also converted the step-by-step guide in the readme into HTML:

    http://www.pretentiousname.com/misc/W7E_Source/win7_uac_poc_details.ht ml

    Now you don’t have to download the source zip or have Visual Studio to see how simple it all is.

  33. Leo Davidson June 13, 2009 at 6:40 am

    (Oops, URLs got mangled in my clipboard. Correct ones here.)

    The source code is now online in HTML format as well. Start here:

    http://www.pretentiousname.com/misc/W7E_Source/Win7Elevate_Inject.cpp.html

    I also converted the step-by-step guide in the readme into HTML:

    http://www.pretentiousname.com/misc/W7E_Source/win7_uac_poc_details.html

    Now you don’t have to download the source zip or have Visual Studio to see how simple it all is.

  34. CDan June 13, 2009 at 6:08 pm

    Actually I like UAC… gives me a feeling of ‘nuthnz happenin behind my back..(that I don’t wan to happen) ‘

  35. Nathan June 16, 2009 at 5:18 pm

    you guys cant have it both ways here

    1.run as admin with the slider all the way up and get a bunch of click through security prompts (kind of worthless)
    2. run as an admin with default settings (still have to trust an outside app, but then you get less prompts – risky, but still safer than no uac)
    3. run as standard user and actually be safe

    you cant ask for auto elevation and then demand that it is 100% secure.

  36. Leo Davidson June 16, 2009 at 6:58 pm

    @Nathan:

    The current defaults make no sense as they make the prompts trivial to bypass and yet still show the prompts (despite them being next to worthless) for some actions. They are the worst of both worlds.

    i.e. Either the mode should be “always prompt” or it should be “silently elevate.”

    If you think the prompts are worthless, even in “always prompt” mode, then feel free to argue the case for “silently elevate.” I don’t think you can argue for the current defaults, though, as they still impose some prompts* which are orders of magnitude more useless than those you get at the “always prompt” level. (* Quite unfairly on 3rd party software, too, when most of the prompt-spamming nightmare is Microsoft’s own apps’ fault.)

    Running as standard user is about as likely to happen as people switching to Linux, until it’s made less annoying. (People would not put up with the prompts in Vista so they sure as hell will not put up with the even worse prompts with standard user. The prompt-spamming nightmare still exists for standard users — because MS haven’t improved the way their apps use UAC, they just gave themselves a UAC backdoor when in limited-admin mode — and is more annoying as you have to type a password for every prompt.)

    Also, prompt-spoofing can be done even with standard user accounts. Nothing is 100% secure. That doesn’t mean we shouldn’t ask for the right balance of security and convenience and complain when Microsoft not only get that balance wrong but serve up a design which is clearly based on marketing and security theatre rather than sound design or logic. (i.e. They’ve made the prompts trivial to bypass by default, but still show the odd prompt for 3rd party software just to give naive users the illusion that there’s some kind of security.)

  37. Chris Corio June 18, 2009 at 11:08 pm

    I was part of the team that designed UAC. I’ll give you a little insight into the history of UAC and address some of the comments made on this blog post. Here we go…

    As with any major initiative, especially one involving a multi-year effort involving 10s of engineers and affecting every application on the face of the earth, you don’t always end up with the exact technology you envisioned when you started. Hell, in the case of UAC we even changed the name of the feature several times – I bet no one remembers that it was called Flexible Account Control Technologies at one point. :)

    If my memory serves me, when we started the UAC project, we firmly believed it would be a security feature. We wanted to protect users on the Windows system from malware. We also had the goal of incentivizing the use of Standard User accounts, which is something MSFT has been trying to do for several releases of Windows.

    From my perspective, the design was brilliant and I take no credit for the creation of the split token. That concept was extremely powerful though because it modeled the default token to be that of a Standard User. In Vista, there was no compromise when it came to prompting and I remember answering the question “is there a white list for applications?” in every UAC talk I ever gave. Have no false pretense, that prompt isn’t security theatre – it is a giant stop sign that says: “This ISV wrote software that unnecessarily requires Administrator privileges!” This is exactly why you see the prompts today on Windows 7 targetted at 3rd parties.

    As for the security messaging around UAC. The point where our messaging switched from security to reliability was when the product team engaged the support of our Secure Windows Initiative (SWI) team to PenTest UAC. They clearly demonstrated because of the shared state, HKCU, user profile, etc., between the “little Abby” and “big Abby” tokens (as we referred to them) that UAC elevations could never be a security feature – this was also right around when MarkRuss came to MSFT. He was also instrumental in demonstrating the flaws in our messaging!

    I’ll admit that the product team was taken aback by this change in messaging and it took some of us longer than others to adjust to the new messaging. The good news is that I believe everyone at MSFT recognizes that UAC elevations (particularly for PA accounts, but also for Standard User accounts) is not a security boundary. If you want the highest level of security…never elevate a standard user account in an interactive session – this is achievable in an enterprise.

    I have personally corrected several of the old documents with that messaging and I’m happy to fix any others if you send me an email with the link: chris@chriscorio.com. I didn’t see any in the top 10 in the list that accompanies this blog post (most of which are not written by offical MSFT employees) aside from the Windows help, which demonstrates the vintage of the messaging: http://windowshelp.microsoft.com/Windows/en-US/help/0eeb9ddd-ddaa-4cc5-a092-9908305665471033.mspx

    Now, where are we today? I’ve seen an incredible interest from IT professionals in running their systems as Standard Users. This is a giant success and UAC was integral in achieving it. Those machines will run smoother and more reliably. As pointed out on the thread, the default account created in the Windows Out-of-Box Experience is still an Administrator. This is disappointing for me but MSFT has prioritized the UX for Windows right now and I think it is a necessary focus. Hopefully we will see this change in the future.

    If anyone would like to have a public debate about UAC at any time – please don’t hesitate to let me know. Just send over a list of questions and I’m happy to answer them. I will be blunt in saying that I regard the dramatic posts around this elevation vulnerability as simply being a laughable distraction.

    One thing that should never be forgotten: Malware writers are very sophisticated. They surely have far more interesting exploits than this fairly rudimentary workaround. And, for all you security researchers out there, this debate makes me chuckle…why does malware need administrator privileges anyway?

    For now, I’m focusing on moving the broader industry to Standard User accounts, one desktop and one more fixed application at a time.

    Chris

  38. Leo Davidson June 19, 2009 at 6:24 am

    It’s great to see some solid info from someone involved with UAC, Chris. Thank you!

    “The good news is that I believe everyone at MSFT recognizes that UAC elevations (particularly for PA accounts, but also for Standard User accounts) is not a security boundary. If you want the highest level of security…never elevate a standard user account in an interactive session – this is achievable in an enterprise.”

    Thank you for including Standard User in that.

    Essentially, no matter which type of account you start from, if you elevate *at all* (or share anything at all, e.g. download something from the web as Standard User, then switch to Admin to view or install it), there is no security boundary.

    But most of the dismissals of the UAC issues in Win7 (and Vista for that matter) have revolved around the split-token Admin account not being a security boundary (true) and implied that if people want a security boundary they must switch to Standard User (false, and unrealistic as the password prompts are so annoying and the level of prompting the same as it was in Vista).

    The other dismissals have said there’s no difference between spoofing prompts and code that can immediately/silently elevate itself, because users are dumb and accept every prompt shown to them. Again, even if true, that applies equally to Standard User.

    If we believe the dismissals are valid then don’t we have to conclude:

    * If you know the administrator password then there is no security boundary for any type of account.

    * If you know password then you might as well run everything as Administrator with UAC prompts switched off, like on Windows XP.

    * UAC[1] has done nothing to improve the security of the millions of self-administrator home users.

    ([1] Ignoring protected-mode IE, which is obviously a good thing. UAC covers many features and it’s easy to accidentally make statements about all of them when you don’t mean to.)

    If not then which part of Microsoft’s logic/statements am I’m missing or misunderstanding? And what are they actually saying (other than “please ignore these issues”)?

    Note: I disagree with the conclusion! I think the dismissals it is derived from miss several key points. To me the dismissals say “it wasn’t perfect before and it is still not perfect, therefore it has not become worse,” which is a ridiculous statement. Much of the rest of this post is playing devil’s advocate by pretending the dismissals and the conclusion are valid.

    Regardless of the conclusion, I think it’s a very good thing that UAC helps developers write software that works on locked-down corporate builds, and also helps corporations select software which they know will work.

    However, if that is the only purpose of UAC (ignoring protected-mode IE again), then why are the UAC prompts on by default for home users?

    1) UAC does assist developers notice when their code depends on administrator rights by accident.

    Programmers typically run under admin accounts — they often need to modify HKLM or run tools like Process Monitor — so it’s easy for them to write code that only works as admin without noticing unless they test everything under another account. UAC helps programmers spot these mistakes by making such code fail unless the programmer modifies it (or the whole exe) to explicitly request admin rights. Good.

    What developers do to fix the problem is up to them. UAC doesn’t stop developers from doing dumb things; nothing can or will. Chances are any programmer too dumb/lazy to minimize the use of admin rights will just set their entire exe to require elevation, making it trivial to detect what they’ve done and ignore their software if it’s important. They’ll sell fewer copies because of their stupid choices. Good!

    2) UAC does assist corporate IT in evaluating whether or not software will work on a locked-down build.

    Corporate IT purchasers can examine exe manifests to see which programs require elevation just to run. They can switch to Always Prompt (or, better, just run as a standard user) while evaluating software to see which exes use COM elevation gratuitously.

    Neither of those things requires UAC prompts to be on by default for the millions of usual self-administrator home users, though. So why are they on? It seems like security theatre to me, now that we’re being told the prompts are not for security.

    Are we really pissing off lots of self-admin users with the default settings just to add an extra incentive for ISVs to do the right thing? Surely if some shoddy developer decides he cannot be bothered supporting Standard User properly then that’s his dumb choice and, so long as it’s easy to tell that’s what he’s done, who cares? The benefit of UAC is helping developers realise their mistakes, not coercing them to fix them. Some developers will always do dumb things. That’s life. Help the good ones do the right thing, educate people about why it’s important, and forget the idiots who ignore it.

    We were told it was important to force all software — even the badly written stuff only used by home users — to work as Standard User so that one day everbody would move to that account type and be more secure without having to sacrifice any of their — potentially crappy — software. But what’s the point of that goal if we’re now being told that, if you join up the dots, Standard User is no more secure than Administrator was if you know the admin password?

    “why does malware need administrator privileges anyway?”

    Isn’t that like asking why we have Standard User accounts? :)

    Malware doesn’t *need* administrator privileges but it can do more damage — or hide itself better as a rootkit — if it gets them.

  39. AndyC June 19, 2009 at 7:31 am

    Chris, great to see your input. As a Systems Administrator on a Vista network I’m well aware of what UAC is and isn’t as regards a security effort and, as you mention above, already block Over-The-Shoulder elevations and insist IT guys use Fast User Switching to perform Administrative tasks should they ever need to on an workstation.

    Which leads me to this comment ” I’ve seen an incredible interest from IT professionals in running their systems as Standard Users. This is a giant success and UAC was integral in achieving it. Those machines will run smoother and more reliably.” Absolutey, I couldn’t agree more, and that’s why I am so gutted to see the desicion to allow silent elevations be the default in Windows 7. All that good work that went into Windows Vista on UAC at reducing the amount of IT time wasted getting applications to run in a Standard User environment is going to fall away as developers take the easy option of hacking their apps to auto-elevate rather than fix the properly, history has shown that devs will generally take the easy option rather than the right one.

    The silent UAC elevation issue really isn’t about malware, it’s about keeping that separation going. Please, for once, won’t somebody think of the admins….

  40. jon June 19, 2009 at 9:03 am

    “This ISV wrote software that unnecessarily requires Administrator privileges!”

    And that therein is the crux of the matter. Microsoft wrote the OS, so their apps (and by this, largely, we mean Explorer) doesn’t need to prompt, whereas other software does.

    Fine, I can accept that (although it is anti-competitive, if you write file managers for a living. But leaving that aside…)

    Given that this vulnerability allows any software to bypass the prompts almost as easily as Microsoft can, what, prey-tell, is actually the point of them?

    The user isn’t interested in whether the ISV wrote software that unnecessarily requires Administrator privilege or not. The user is interested in getting something done. The software they’re using presumably (if we give it the same benefit of the doubt that Microsoft give their own apps) NEEDS administrator privilege for a reason. All the user sees is a prompt which annoys them and interrupts their workflow. It’s clearly not for security (as you have admitted, and as can easily be shown since it can now – not in Vista, but in Windows 7 – be trivially bypassed), and any “lesson” that the prompts bring is one for the developer themselves, not their customers.

    UAC was a good idea that was imperfectly implemented. Most of the criticism of unnecessary prompting was because of Microsoft’s own stupidity – I mean, come on – FOUR individual prompts just to create a folder and rename it in Program Files? Instead of fixing this, you have now turned the tables and decided to give yourselves a free pass, and penalize any ISVs who tried to play by your rules and do the right thing. The users will continue to be annoyed, but by third-party software instead of by Microsoft’s.

    Well done all round.

  41. Leo Davidson June 21, 2009 at 4:43 am

    “why does malware need administrator privileges anyway?”

    http://en.wikipedia.org/wiki/Conficker#Operation — Self-Defence column

  42. Chris Corio June 21, 2009 at 8:41 pm

    Thanks to everyone for your responses. I will try to address the comments/questions individually. This will be lengthy. :)

    I’m not a huge fan of blog posts overall because they tend to get very fragmented and the actual flow of ideas can be very difficult to follow… Everyone should have my email address and you’re all welcome to email me with any questions…you can post my responses in email if you’d like. From here on out, I’ll probably be slow to watch the comments on this blog post…

    Also, forgive me for being particularly exacting in my language in certain spots but it’s very important that we use specific terminology carefully. I’m not going to delve deeply into the security boundary language right now because I expect to collaborate on a TechNet magazine article that describes them thoroughly. Very briefly, a “security boundary” exists when certain “security guarantees” have been articulated that define the boundary.

    I will also openly state that none of my comments represent Microsoft’s views…they are my own.

    From Leo’s comment, he writes:
    “But most of the dismissals of the UAC issues in Win7 (and Vista for that matter) have revolved around the split-token Admin account not being a security boundary (true) and implied that if people want a security boundary they must switch to Standard User (false, and unrealistic as the password prompts are so annoying and the level of prompting the same as it was in Vista).
    The other dismissals have said there’s no difference between spoofing prompts and code that can immediately/silently elevate itself, because users are dumb and accept every prompt shown to them. Again, even if true, that applies equally to Standard User.
    If we believe the dismissals are valid then don’t we have to conclude:
    * If you know the administrator password then there is no security boundary for any type of account.
    * If you know password then you might as well run everything as Administrator with UAC prompts switched off, like on Windows XP.
    * UAC[1] has done nothing to improve the security of the millions of self-administrator home users.
    ([1] Ignoring protected-mode IE, which is obviously a good thing. UAC covers many features and it’s easy to accidentally make statements about all of them when you don’t mean to.)
    If not then which part of Microsoft’s logic/statements am I’m missing or misunderstanding? And what are they actually saying (other than “please ignore these issues”)?”

    Specifically addressing your parenthetical comment: “(false, and unrealistic as the password prompts are so annoying and the level of prompting the same as it was in Vista)” I run all of my computers as a Standard User every day. I am rarely prompted. I went so far as to write a piece of software that catalogs all of the UAC prompts that I see just so that I could be sure. I’m happy to share this software with anyone that would like to test this out. In enterprises without proper infrastructure to manage software deployment and policy configuration, yes, I could see this configuration being unrealistic.

    I’m not sure exactly what security guarantee would be broken and what corresponding security boundary would be in jeopardy when the administrator password is known. (Notice I am using the terms formally) If an entity has the administrator password they can log onto the computer and do anything an administrator can do. Your system may be in an insecure state but no security boundary has been explicitly broken.

    As for the rest of Leo’s comments, I look at where we are today as an incremental step. I will venture to say (without providing formal references) that my system runs more reliably with UAC enabled. And if you look at UAC as a long term strategic initiative to enable home users to run as Standard User accounts that never elevate then I think that we have provided home users some benefit although it may not immediately be realized. (I hint at this in the beginnings of my UAC article on MSDN – link below.) If you combine standard user accounts with something like App Locker, you’re getting even closer to a very secure desktop user experience. Once again, I’ll issue a caveat by saying that I have no notion of whether this is Microsoft’s current thinking.

    AndyC –
    I agree that the automatic elevation policy is disheartening though I think that its implementation is fair and I don’t think there’s much change in incentives for 3rd parties to “auto-elevate” a piece of software. The implementation is designed to avoid this and an ISV could always write a service or use a Windows Task to auto-elevate in Windows Vista.

    While this feature was implemented after I left MSFT, I’ll try to speculate around the motivation for the feature: I think the negative backlash around the Vista UX, largely impacted by UAC, was particularly heartfelt by the newly appointed Windows executive management chain and this problem was to be solved! Like I said, I can completely understand the focus on UX and so the pendulum swung. I will say two things:
    1. I have my suspicions that MSFT was thrown a curveball. What I mean by that is that the loudest critics were the pundits that primarily install and configure their systems all day and would thus see a lot of prompts. If anyone knows me well, they know I’m particularly curious about people’s impression of technology and I’m apt to ask anyone at length about their experience on Windows. I always ask “lay-home-users” whether prompts are an issue and I generally find that they don’t see many prompts.
    2. I think the internal mandate for change was slightly disconnected from reality. The engineers at MSFT fixed a lot scenarios that caused prompts in Windows, including the one that jon points out for folder creation and renaming (which was fixed in Vista SP1), and the industry would have been 3 years into fixing their prompts by the time at Windows 7 ships. I think that the prompt problem would have naturally solved itself but I’ve always tended to have a bit of a laissez faire attitude toward the prompting problem…

    But, alas, this problem was to be solved!! And thus you see the automatic elevation for specific Windows applications. Please be aware that you cannot arbitrarily elevate all in-box Windows binaries – the feature was focused on scenarios where the system was being configured. In the end, I believe this feature will continue to incentivize 3rd parties to develop for Standard User accounts.

    Jon, you wrote:
    “And that therein is the crux of the matter. Microsoft wrote the OS, so their apps (and by this, largely, we mean Explorer) doesn’t need to prompt, whereas other software does.”

    Most applications shouldn’t need to prompt at all – Windows applications or otherwise – but for legacy reasons many should and do during installation. Explorer.exe definitely doesn’t need to prompt because it always runs with the Standard User token. Certain file management scenarios are an exception, including folder creation in protected areas of the file system, and these are handled by COM objects that are automatically elevated. If you want to implement your software with a similar UX, it’s possible and I’d be happy to walk through certain design scenarios with you to achieve this user experience.

    Lastly, I will point you at this link and say, I had the pleasure of working for David and he is awesome, I agree with everything in this article. http://news.cnet.com/Microsoft-Vista-feature-designed-to-annoy-users/2100-1016_3-6237191.html

    Leo, referencing my original post, you wote:
    “why does malware need administrator privileges anyway?”
    http://en.wikipedia.org/wiki/Conficker#Operation — Self-Defence column

    I would refer you to the “Initial Infection” section. No UAC prompt was required for infection, which is what I meant when I said, “why does malware need administrator privileges anyway?” Sorry for the confusion. Your example does illustrate the sophistication of malware developers, which was my original intent.

    Phew…I think that addresses most of the comments. Ultimately, computer security, like any other security field, is a very intense and challenging problem where two opposing sides fight to protect and compromise resources and always will. I view technology changes within this context. If you want a look at a similar discussion put in the context of physical lock technology, here’s an awesome article from Wired magazine: http://www.wired.com/techbiz/people/magazine/17-06/ff_keymaster?currentPage=all

    Send me emails for further comment.

    Cheers,
    Chris

  43. Leo Davidson June 22, 2009 at 7:38 am

    (Sent via email as well.)

    <>

    I run standard user on my HTPC and that’s fine, too. I could probably do the same on my laptop. On my development desktop I think it be too much to type a password every time I run Process Monitor, RegEdit, etc. (Plus the hassle of tools like RegEdit which don’t let you elevate from within them if launched as standard user.) Those aren’t things typical users would be doing, though.

    For the average user I think the problem was them extrapolating from the annoyance of “the first two weeks” setting up the machine. All those control panels, installers, etc., plus the prompts-about-prompts in Explorer if they had to touch Program Files for some reason. The secure desktop was also annoying for some. (Sometimes it takes several seconds to switch to and from the secure desktop for some reason. Dimming the entire screen annoys people with large/multiple monitors.)

    I’ve always told people that if they feel they must switch off the prompts then they should try turning them on again in a couple of weeks as they probabaly won’t bother them anymore. That was based on the assumption that the prompts had some value to the users who see them, though.

    Whether people’s irritation was sensible or not, it did exist, however.

    1) MS knew it and the auto-elevation changes in Windows 7 are to make those people happy. They are the default mode so I’m assuming it’s what MS think most people want.

    2) MS also know that standard user accounts are basically unchanged from Vista, with the prompts as frequent and more annoying than the limited-Admin mode people were complaining about.

    Combine those two and MS cannot expect most people to move to standard user accounts at this time. Rather than encourage it MS have actually made sticking with an admin account *more* tempting with Windows 7. It’s a step backwards.

    Something had to be done but I’m not convinced this was the right thing.

    <>

    I consider UAC elevation/prompts largely irrelevant to enterprises. They were (or should have been) already using standard user accounts, are unlikely to use OTS elevation (perhaps some tiny companies will take advantage of it, though) and they were already selecting/demanding/verifying tools which worked without admin rights and large software companies were already producing such software.

    I’ve always seen UAC as something for home users, not enterprises, except that it encourages more amateur software to be written in a way which works with enterprise setups (something which enterprises still need to test as UAC doesn’t *guarantee* that apps don’t require admin; it just makes it easier for developers to notice the problem).

    (As before, I’m not talking about protected-mode IE etc. here. That’s obviously good for enterprises and everyone else.)

    <>

    As soon as you have a non-elevated process talking to an elevated object, you’ve created a hole in the security boundary, even with standard user. A peer of the unelevated process could hijack it and take over its object. This is difficult to do but possible. Similarly, having any elevated UI objects on the same desktop as unelevated ones has breached the security boundary, even with standard user and even with the (incomplete) protection of UI isolation, etc.

    All of which is fine. Elevation is a compromise between security and convenience.

    However, Microsoft’s arguments for dismissing the code-injection issue revolve around the fact that there isn’t a security boundary with limited-Admin accounts. Well there isn’t one with standard user accounts, either, if elevation is used at all. So either MS need to openly say “we don’t care about any holes in UAC, even for standard user,” or they need to come up with a better explanation for why they don’t care about holes for limited-admin accounts.

    “It’s not a security boundary” isn’t a good enough reason to ignore one mode when neither mode is a security boundary.

    <>

    Microsoft, at times, seem to be claiming that there’s no difference between these two situations (both about the default setups on each OS):

    - On Vista, unelevated code can gain admin by displaying a spoofed UAC prompt and tricking the user into accepting it.

    - On Windows 7, Unelevated code can gain admin silently and immediately.

    The argument of equivalence requires that all users will blindly consent to every UAC dialog they see. By this argument the distinction between the user and the code they run is lost. Essentially, if the user knows the password then the code has the password, too. I disagree, but it’s not my argument. If we believe this argument then surely, like the security boundary argument, it means that standard user accounts are no more secure than admin accounts.

    Why are the people advocating those two arguments also advocating standard user accounts? Standard user accounts fail both of their arguments as well.

    <>

    That initiative seems to have stalled. Windows 7 made very little progress towards “standard user for everyone.” In fact, it’s made admin accounts more tempting while the standard user experience has stood still. This is why I find it irritating when MS say people should use standard user if they actually want security: They know standard user is still too irritating for too many, that it cannot be the default as a result, and rather than improve things they’ve moved backwards. In addition, their arguments for ignoring holes in limited-admin apply to standard user.

    <>

    Jon’s folder creation case is the only one I’m aware of that was actually improved. I don’t use Explorer much but from using it briefly on Vista SP2 and Windows 7 (in standard user or always prompt modes), it’s abundantly clear that Explorer is still full of cases where a single action triggers multiple prompts. The first prompt usually exists just to tell you you’re about to see a second prompt. (Either because someone took the dubious UX guideline that “you must show a UAC shield before showing a UAC prompt” too literally, or because they felt the need to display additional information that couldn’t be displayed in the actual UAC, due to the poor design of the prompts/elevation process.) Add to this the additional “Are you sure?” prompts, which are not optional, and you sometimes have to click three times for one action. It’s ridiculous and extremely irritating.

    (It’s also silly that Explorer still shows the prompts-about-prompts in the default Win7 UAC mode, without displaying the UAC prompts themselves. MS got rid of the prompts that provided some security and left in the ones which code can suppress and which only tell you what you already know with no guarantee that it’s actually what the admin object has been passed.)

    On top of that, there is no way for standard user or “always prompt” users to enter an OS X-style (or Directory Opus-style) timed “admin mode” (without switching users, changing system-wide UAC settings, or killing the entire shell and re-launching it elevated) where they can perform several admin actions in a row without triggering multiple prompts.

    An “admin mode” is obviously a security hole while it is active — for the same reasons elevation in general is a security hole — but it seems hard to argue against such a mode when the default for Windows 7’s Explorer is, effectively, “admin mode” 24/7 even when the user isn’t present.

    <>

    Jon’s already written a file manager which uses UAC/COM elevation. It does a better job than Microsoft’s Explorer code (even if you ignore the folder-creation improvements in Vista SP1). Two comparison videos here, both made in 2007:

    http://www.pretentiousname.com/misc/win7_uac_whitelist2.html#comparison

    <>

    AFAIK it’s not possible to create a file manager (or task manager or registry editor or…) with the same UX as Windows 7’s built-in tools without resorting to hacks or the effort of writing services*. Is that not the case? If there’s another way it’d be great to know it.

    If nobody cares that it’s possible to bypass the prompts, even via methods such as code-injection that don’t require admin or installation at any prior point, wouldn’t it be better to give users the ability to explicitly white-list third-party apps and/or COM objects? If whitelisting makes sense at all then it should be user-configurable.

    (*Writing a service is easy. Writing a good service is hard. Writing one which exposes admin APIs in a secure way and properly validates all requests is even harder. Still preferable to using a code-injection hack that could stop working at any time, but I’m not sure it’s the answer. If we’re going to dismiss the idea of preventing code getting admin then I’d rather we just did that, and gave users a whitelist, instead of putting up with badly-written services that run 24/7 and expose admin APIs to any process that knows their protocol. There are exceptions, of course. It’s worth doing when something is a non-admin tool and needs an admin-side components to do something. e.g. The Steam game distribution/DRM system must be able to work for people who don’t know the admin password and it has an admin service which starts and stops with the game-launching client. I’m not convinced there’s a good reason for Steam to require admin rights in the first place — I suspect it’s for DRM systems and not for anything that benefits the user — but it is an example where a whitelist woudldn’t solve the problem and a service does.)

    <>

    I agree that admin rights were not required for the initial infection and that the flaws allowing that infection (and people not installing updates) are/were more important by far.

    There is a steady stream of those flaws, though, so it is unrealistic to say, “let’s ignore damage limitation and focus only on infection prevention.” That’s especially true when companies like Adobe think that weeks/months is a rapid response time for in-the-wild exploits.

    You seemed to be laughing at people for talking about admin rights and malware in the same sentence, but being able to get admin rights made Conficker a bigger problem because it broke/blocked tools/updates which would have removed it after the infection.

  44. Leo Davidson June 22, 2009 at 7:52 am

    Doh, the chars I used for quoting meant parts of the post were interpreted as HTML. Reposting it here.

    Also something I forgot to say:

    I think the “sensationalist” response is because people thought UAC, and the irritation it caused, existed *at least in part* to improve their security today. The current strong reactions are because MS don’t seem to care about this particular problem with UAC. Imagine how strong the reactions will be if people realise that MS don’t care about *any* issues with UAC? MS claim that’s been their message all along, but it hasn’t been. The overriding message with Vista was that UAC was a security feature but not an air-tight security boundary. Now it seems its the message is that UAC exists only to annoy users to make them pester programmers. If MS clarify that message, as they say they want to, then I think we’ll see more “sensationalist” responses, not less.

    Here’s the original reply without the HTML characters:

    (Sent via email as well.)

    [ I run all of my computers as a Standard User every day. ]

    I run standard user on my HTPC and that’s fine, too. I could probably do the same on my laptop. On my development desktop I think it be too much to type a password every time I run Process Monitor, RegEdit, etc. (Plus the hassle of tools like RegEdit which don’t let you elevate from within them if launched as standard user.) Those aren’t things typical users would be doing, though.

    For the average user I think the problem was them extrapolating from the annoyance of “the first two weeks” setting up the machine. All those control panels, installers, etc., plus the prompts-about-prompts in Explorer if they had to touch Program Files for some reason. The secure desktop was also annoying for some. (Sometimes it takes several seconds to switch to and from the secure desktop for some reason. Dimming the entire screen annoys people with large/multiple monitors.)

    I’ve always told people that if they feel they must switch off the prompts then they should try turning them on again in a couple of weeks as they probabaly won’t bother them anymore. That was based on the assumption that the prompts had some value to the users who see them, though.

    Whether people’s irritation was sensible or not, it did exist, however.

    1) MS knew it and the auto-elevation changes in Windows 7 are to make those people happy. They are the default mode so I’m assuming it’s what MS think most people want.

    2) MS also know that standard user accounts are basically unchanged from Vista, with the prompts as frequent and more annoying than the limited-Admin mode people were complaining about.

    Combine those two and MS cannot expect most people to move to standard user accounts at this time. Rather than encourage it MS have actually made sticking with an admin account *more* tempting with Windows 7. It’s a step backwards.

    Something had to be done but I’m not convinced this was the right thing.

    [ In enterprises without proper infrastructure to manage software deployment and policy configuration, yes, I could see this configuration being unrealistic. ]

    I consider UAC elevation/prompts largely irrelevant to enterprises. They were (or should have been) already using standard user accounts, are unlikely to use OTS elevation (perhaps some tiny companies will take advantage of it, though) and they were already selecting/demanding/verifying tools which worked without admin rights and large software companies were already producing such software.

    I’ve always seen UAC as something for home users, not enterprises, except that it encourages more amateur software to be written in a way which works with enterprise setups (something which enterprises still need to test as UAC doesn’t *guarantee* that apps don’t require admin; it just makes it easier for developers to notice the problem).

    (As before, I’m not talking about protected-mode IE etc. here. That’s obviously good for enterprises and everyone else.)

    [ I'm not sure exactly what security guarantee would be broken and what corresponding security boundary would be in jeopardy when the administrator password is known. ]

    As soon as you have a non-elevated process talking to an elevated object, you’ve created a hole in the security boundary, even with standard user. A peer of the unelevated process could hijack it and take over its object. This is difficult to do but possible. Similarly, having any elevated UI objects on the same desktop as unelevated ones has breached the security boundary, even with standard user and even with the (incomplete) protection of UI isolation, etc.

    All of which is fine. Elevation is a compromise between security and convenience.

    However, Microsoft’s arguments for dismissing the code-injection issue revolve around the fact that there isn’t a security boundary with limited-Admin accounts. Well there isn’t one with standard user accounts, either, if elevation is used at all. So either MS need to openly say “we don’t care about any holes in UAC, even for standard user,” or they need to come up with a better explanation for why they don’t care about holes for limited-admin accounts.

    “It’s not a security boundary” isn’t a good enough reason to ignore one mode when neither mode is a security boundary.

    [ If an entity has the administrator password they can log onto the computer and do anything an administrator can do. Your system may be in an insecure state but no security boundary has been explicitly broken. ]

    Microsoft, at times, seem to be claiming that there’s no difference between these two situations (both about the default setups on each OS):

    - On Vista, unelevated code can gain admin by displaying a spoofed UAC prompt and tricking the user into accepting it.

    - On Windows 7, Unelevated code can gain admin silently and immediately.

    The argument of equivalence requires that all users will blindly consent to every UAC dialog they see. By this argument the distinction between the user and the code they run is lost. Essentially, if the user knows the password then the code has the password, too. I disagree, but it’s not my argument. If we believe this argument then surely, like the security boundary argument, it means that standard user accounts are no more secure than admin accounts.

    Why are the people advocating those two arguments also advocating standard user accounts? Standard user accounts fail both of their arguments as well.

    [ And if you look at UAC as a long term strategic initiative to enable home users to run as Standard User accounts that never elevate then I think that we have provided home users some benefit although it may not immediately be realized. ]

    That initiative seems to have stalled. Windows 7 made very little progress towards “standard user for everyone.” In fact, it’s made admin accounts more tempting while the standard user experience has stood still. This is why I find it irritating when MS say people should use standard user if they actually want security: They know standard user is still too irritating for too many, that it cannot be the default as a result, and rather than improve things they’ve moved backwards. In addition, their arguments for ignoring holes in limited-admin apply to standard user.

    [ The engineers at MSFT fixed a lot scenarios that caused prompts in Windows, including the one that jon points out for folder creation and renaming (which was fixed in Vista SP1) ]

    Jon’s folder creation case is the only one I’m aware of that was actually improved. I don’t use Explorer much but from using it briefly on Vista SP2 and Windows 7 (in standard user or always prompt modes), it’s abundantly clear that Explorer is still full of cases where a single action triggers multiple prompts. The first prompt usually exists just to tell you you’re about to see a second prompt. (Either because someone took the dubious UX guideline that “you must show a UAC shield before showing a UAC prompt” too literally, or because they felt the need to display additional information that couldn’t be displayed in the actual UAC, due to the poor design of the prompts/elevation process.) Add to this the additional “Are you sure?” prompts, which are not optional, and you sometimes have to click three times for one action. It’s ridiculous and extremely irritating.

    (It’s also silly that Explorer still shows the prompts-about-prompts in the default Win7 UAC mode, without displaying the UAC prompts themselves. MS got rid of the prompts that provided some security and left in the ones which code can suppress and which only tell you what you already know with no guarantee that it’s actually what the admin object has been passed.)

    On top of that, there is no way for standard user or “always prompt” users to enter an OS X-style (or Directory Opus-style) timed “admin mode” (without switching users, changing system-wide UAC settings, or killing the entire shell and re-launching it elevated) where they can perform several admin actions in a row without triggering multiple prompts.

    An “admin mode” is obviously a security hole while it is active — for the same reasons elevation in general is a security hole — but it seems hard to argue against such a mode when the default for Windows 7’s Explorer is, effectively, “admin mode” 24/7 even when the user isn’t present.

    [ Certain file management scenarios are an exception, including folder creation in protected areas of the file system, and these are handled by COM objects... ]

    Jon’s already written a file manager which uses UAC/COM elevation. It does a better job than Microsoft’s Explorer code (even if you ignore the folder-creation improvements in Vista SP1). Two comparison videos here, both made in 2007:

    http://www.pretentiousname.com/misc/win7_uac_whitelist2.html#comparison

    [ ... that are automatically elevated. If you want to implement your software with a similar UX, it’s possible and I’d be happy to walk through certain design scenarios with you to achieve this user experience. ]

    AFAIK it’s not possible to create a file manager (or task manager or registry editor or…) with the same UX as Windows 7’s built-in tools without resorting to hacks or the effort of writing services*. Is that not the case? If there’s another way it’d be great to know it.

    If nobody cares that it’s possible to bypass the prompts, even via methods such as code-injection that don’t require admin or installation at any prior point, wouldn’t it be better to give users the ability to explicitly white-list third-party apps and/or COM objects? If whitelisting makes sense at all then it should be user-configurable.

    (*Writing a service is easy. Writing a good service is hard. Writing one which exposes admin APIs in a secure way and properly validates all requests is even harder. Still preferable to using a code-injection hack that could stop working at any time, but I’m not sure it’s the answer. If we’re going to dismiss the idea of preventing code getting admin then I’d rather we just did that, and gave users a whitelist, instead of putting up with badly-written services that run 24/7 and expose admin APIs to any process that knows their protocol. There are exceptions, of course. It’s worth doing when something is a non-admin tool and needs an admin-side components to do something. e.g. The Steam game distribution/DRM system must be able to work for people who don’t know the admin password and it has an admin service which starts and stops with the game-launching client. I’m not convinced there’s a good reason for Steam to require admin rights in the first place — I suspect it’s for DRM systems and not for anything that benefits the user — but it is an example where a whitelist woudldn’t solve the problem and a service does.)

    [ I would refer you to the "Initial Infection" section. No UAC prompt was required for infection, which is what I meant when I said, "why does malware need administrator privileges anyway?" Sorry for the confusion. Your example does illustrate the sophistication of malware developers, which was my original intent. ]

    I agree that admin rights were not required for the initial infection and that the flaws allowing that infection (and people not installing updates) are/were more important by far.

    There is a steady stream of those flaws, though, so it is unrealistic to say, “let’s ignore damage limitation and focus only on infection prevention.” That’s especially true when companies like Adobe think that weeks/months is a rapid response time for in-the-wild exploits.

    You seemed to be laughing at people for talking about admin rights and malware in the same sentence, but being able to get admin rights made Conficker a bigger problem because it broke/blocked tools/updates which would have removed it after the infection.

  45. MadHopsMan June 26, 2009 at 8:16 am

    HAHAHA! That gave me good chuckle. Your way with words is quite elegant, I must say :)

  46. Diego Fernandez June 26, 2009 at 10:42 pm

    Hi, interesting discussion.
    I’m not a Windows expert so maybe my question is too naive: why Windows doesn’t use standard user accounts in similar way to Linux, MacOSX or other unixes?

    For example in Ubuntu you always run with a standard user (in fact you can’t login with a root user), the only way to run admin commands is to use “sudo”, which from the user point of view is similar to a UAC prompt asking for a password. (the same happens in MacOSX).

    As a user the main difference is that in Vista UAC prompts feels random and annoying, for example if you run a program called “install” you get a UAC prompt!! Even if the program is not doing anything that requires privileges.

    To me the main problem of standard user accounts in Windows is that most of the programs are not designed to be installed in isolation from the rest of the system.
    For example if you are a web developer you could install Java and a application server in your home directory and use it without problem, but if you want to develop in .Net you need to install libraries that affects the whole system, so you need admin privs for the installation (the same problem happens to near every MS application: each installation is like a complete OS update)

    I think that the root cause of the “std vs admin account” problem is the same of the unnecessary reboots required by some installation programs: lack of good modularity.

  47. Boomerz July 26, 2009 at 6:01 am

    I think people are forgetting that many people share the same computer. For families that share the same computer, UAC is awesome. A family member may inadvertently download something malicious or mess around with the computer settings which could break the device. I just wanted to bring another perspective rather than the single person with the single computer who does not feels the need for UAC since he or she does not share the or let others borrow it.

  48. vanti August 27, 2009 at 3:20 pm

    OK so initially and internaly in development it is considered a “bug-users nagscreen” to make software developers actually learn how to program their applications properly as Mark Russinovich says. But on the sales guys it is marketed as a security feature.

    Know what. The part of teaching developers to code properly actually worked pretty good. Now the second part. Get the users (especially the stubborn powerusers of olde) to learn not to run with administrator accounts but use limited accounts and typing in the admin password when needed. JUST LIKE INTENDED! This is also btw how it works in linux and OS X.

    If you use std accounts then the UAC really does work as a security shield.