Confusion about Vista Features: What UAC Really Is

As you may know I am just putting the finishing touches on a new book. Roger Grimes and I teamed up to write Windows Vista Security. In the course of doing the research for the book, and just keeping up with the popular press lately, it has become obvious that there is a lot of confusion about User Account Control (UAC) in Vista. The chapter on UAC in the book goes into detail on exactly what UAC is and what it is supposed to do, and I thought I would give a little preview here.

There seems to be a fairly consistent consensus that the purpose of UAC is to block malicious code on your system from horking your system completely. It is not entirely clear where this consensus comes from though. To see whether Microsoft had stated that this was the case I did a brief survey of some of the 1000 or so pages on Microsoft.com that mention "UAC" and one or more of "security feature" and "malware". I was looking for something that claimed that UAC will stop malware that is executing on your system from elevating to an administrator and taking over your system.

I did not look at all of the pages, but the only place I found that meaningfully combined "UAC" and "security feature" was in an IT Showcase white paper that claims:
 "UAC helps reduce the impact of malicious software" (http://www.microsoft.com/technet/itshowcase/content/vistasecurity_twp.mspx)

Almost exactly the same claim is made in the Windows Vista Security Guide:
"This helps reduce the affect[sic] of malware" (http://www.microsoft.com/technet/windowsvista/security/defend_against_malware.mspx)

That's a bit tenous as a claim, but it also stops just short of saying that UAC stops malware, even though it could certainly be interpreted as such by anyone who wanted to. I had more luck combining "UAC with "Malware". The "Defend againsta malware" chapter in the guide features UAC as the primary technology that does this. It recommends running with UAC turned on - for the most part - and it lists a number of mitigation considerations when using UAC to mitigate against malware. One consideration, however, is glaringly missing:

 UAC does not, nor is it intended to, stop malware.

UAC's purpose is to enable more users to run as a standard user. Microsoft may have hinted that its purpose was to stop malware - even more than hinted, in the case of the Vista Security Guide - but this is really incorrect. Of course, one cannot but claim that an attendant goal was to provide some level of protection for apps running as an admin from those that were not, but that was not by any means the primary purpose of UAC. The primary purpose was to start us on a path where more users run as standard user. This in turn will force ISVs to write more programs that work as a standard user, which reduced further the number of situations where users need to elevate. As ISVs write better apps, the number of prompts the user gets goes down, and the user experience is better. In the process we ideally end up in a situation where most people do not run as administrators and, hopefully, start questioning some of the elevation prompts they do get. The fewer they get, the more likely they are to consider them carefully before allowing them, or so the theory goes. By extension, yes, there may be less malware, but it all depends on (a) whether users keep UAC one, (b) which is dependent on whether ISVs will write software that works with it, and (c) users stop considering prompts to be fast-clicking exercises and actually consider whether an elevation request is legitimate or not.

Some of the brightest thinkers in the world regarding Windows security today, such as Joanna Rutkowska, did understand that this was the purpose. As she put it in a blog post on February 4: "User Account Control (UAC) is a new security mechanism introduced in Vista, whose primary goal is to force users to work using restricted accounts, instead working as administrators." (http://theinvisiblethings.blogspot.com/2007/02/running-vista-every-day.html). She has it mostly right in that one, except I would use the term "enable" rather than "force."

This, unfortunately, is also a bit scary for Microsoft. Local privilege escalation vulnerabilities, where a user can escalate from a local standard user to a local administrator, have never been particularly interesting on the Windows platform. Since somewhere around 95% of users on Windows run as administrators, what's the point of escalating? What are you going to escalate to? Another admin?

Well, with Vista the idea is that users will run as standard user instead, and suddenly, local privilege escalation issues become very interesting. Unfortunately, this is also where we run into some of the limitations of UAC. An elevated application runs on the same desktop as a low (non-elevated) application. Windows, just like other operating systems, do not implement complete process isolation between applications on the same desktop. This means that there are certainly ways for a low application to impact what an elevated application can do. There is no security boundary that isolates processes on the same desktop. The OS does include some protective measures to keep the obvious, and unnecessary, avenues of communication blocked, but it would be impossible, and undesirable, to block all. Therefore, Microsoft does not want to consider breaches of that - nonexistent - boundary as security breaches. If they were considered security breaches, it would look horrible for Vista security. Mark Russinovich, a Technical Fellow (extremely exalted engineering deity) at Microsoft pointed out as much in a blog post (http://blogs.technet.com/markrussinovich/archive/2007/02/12/638372.aspx). And so the war of the blogs started.

Joanna responded with "And now we hear what? That this flagship security technology (UAC) is in fact… not a security technology!" (http://theinvisiblethings.blogspot.com/2007/02/vista-security-model-big-joke.html).

The first observation to draw from this is that we now apparently fight it out in blogs. The other is that, well, both are really correct. Let's sort it out.

Mark is totally correct. Microsoft is well aware of the fact that there is no security boundary between a low process and an elevated one on the same desktop. As there was never intended to be one, there really cannot be a security vulnerability when it is discovered that a particular mechanism allows communication between two processes of different integrity or running with different tokens. Obviously, that diminishes the value of UAC as a first-order way to fight malware, but we already accepted the fact that it was not designed to be a first-order way to fight malware anyway. One might only wish that Microsoft had been (a) a little more upfront about this fact and not lead people into believing that UAC provided protection; and (b) a bit more coordinated and not point to UAC as the primary way in which Windows Vista fights malware in the Windows Security Guide. It really is no wonder that people believed that UAC was making promises the product group never designed it to keep.

Does this fact diminish the stated value of UAC (the goal of which, recall, was to enable more people to run as standard user)? No. It does not have any impact on the ability of UAC to achieve that goal at all. The existence or lack of an impervious security boundary between a malicious low app and an elevated application does not change the fact that more users can effectively use UAC and run their Vista computers as a standard user. In fact, contrary to what some in the industry would have you believe, I wrote this entire blog post (and the entire book for that matter) as a standard user on Windows Vista, and not once did I get a UAC prompt asking me to accept anything that I wrote!

Is Joanna correct in taking Mark's statement to mean that UAC is not a security technology? No. It is a security technology, and she already stated, largely correctly, in a previous post, what the goal of this security technology is. The fact that UAC does not mitigate all security problems, or that it does not possess a property that many of us, myself included, would dearly like to have - first-order protection against malware - does not mean it is not a security technology. The ability to identify users by use of separate user accounts, by itself, also does not stop malware from infecting your system, but nobody would stretch that fact into meaning that user accounts, therefore, are not a security technology.

UAC leaves it up to technologies like the vastly improved Windows Firewall, Windows Defender, and other anti-malware programs, to keep malicious code off the box, and to keep it from executing if it gets there. Neither of those is 100% successful at those missions either, but that also does not mean that none of them are security technologies either. All these technologies have their place. But, as I have said many times before, even if all the technical avenues of attack are shut down, it all comes down to the user. If the person behind the keyboard choses to allow malicious code to run, no technical mitigation in the world will help.

What does that mean for UAC though? Should we not use it? No, we really should, especially if we log on as an administrator (which I am happy to say I no longer do on any of my Vista systems). However, how do we mitigate the risk of privilege escalation between processes? It depends on our risk management philosophy. In the book, I laid out the increasing order of security of different ways to become an administrator:

• Good: Run in admin-approval mode
• Better: Run as standard user and elevate to separate admin account
• Best: Run as standard user and switch user to a separate admin account instead of using UAC to elevate

 Pick whichever one of these works best for you and provides you a level of protection you are comfortable with.