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.

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.

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.

<>

<>

<>

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.

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

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

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.

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….

“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.

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

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.)

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.

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.

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.

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.

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!

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.

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.

It wasn’t.