User Account Control Prompts on the Secure Desktop

Imagine stopping at a gas station to fuel up your car, selecting Standard grade unleaded gasoline, and then filling up your gas tank. Imagine then that your car fails to start and that you discover that someone maliciously tampered with the gas pump to make it distribute diesel gasoline instead of unleaded. This is an example of others using faulty information to intentionally mislead people into making bad decisions. And unless you go through great lengths to prove confirmation, there’s no reason to distrust the thing you’re interacting with. We call that “spoofing” in computer lingo, and that’s the focus of this week’s blog topic.

Hi, my name is Jim and I’m a Program Manager working on User Account Control. In previous publicly released builds of Windows Vista™ you saw these prompts show up in near proximity to the window that caused the elevation. There were no other visual changes that occurred and the elevation dialog looked and acted like any other child dialog of a parent window. Additionally, you could cause multiple of these dialogs to come up merely by clicking on other windows with controls decorated with the UAC shield (see Fig 1 for an example).

See larger image
Fig 1. – Links with the UAC Shield indicating privileged tasks

Starting with the Beta 2 release of Windows Vista™ the user experience around User Account Control elevation will change in a way that is meant to provide users with a way that will help them make the best decisions they can based on unadulterated information provided by Windows. That is, we have changed the user experience to block the ability of malicious software that may be on the box waiting to gain elevated privilege to spoof the user interface that displays information to the user.

The elevation prompts will now occur on what is known as the “Secure Desktop”. You most commonly interact with this desktop when you log on to Windows since the Logon UI runs on the Secure Desktop (Fig 2).

See larger image
Fig 2. – Logon UI running on the Secure Desktop

The Secure Desktop’s primary difference from the User Desktop is that only trusted processes running as SYSTEM are allowed to run here (i.e. nothing running as the User’s privilege level) and the path to get to the Secure Desktop from the User Desktop must also be trusted through the entire chain.

So what does this experience look like? When you click on a UAC shielded control, your user desktop will appear to dim and the window that caused the elevation request – typically the window you were most recently using - and the elevation UI will be made more prominent. This is to provide you with the highest level of context possible when interacting with the elevation dialog. It’s worthwhile to note that we could have continued to use the blue-green background that Logon UI uses, but we felt that it was an important part of the overall user experience to maintain as much of your current task context as possible since you were likely in the middle of doing something specific when you were presented with the elevation UI.

[As an aside, if you see a window show up – or perhaps no window at all - that you weren’t expecting, this should be a cause for caution since Windows™ should not be asking you for elevation without the user initiating the process].

See larger image
Fig 3. – Example of an unsigned –therefore unknown - application

The dialog itself already has as much trustworthy information as the operating system can get (see the previous blog entry “What's New in the February CTP” for more information on this) and we are also supplying the parent window to ensure the user understands what’s asking for elevation. If, for example, some strange window shows up with an orange banded elevation UI, that means that Windows™ cannot give you information about who published the application that wants to elevate. If you don’t know where this application came from (e.g. Did it come from the disc that you just put in the CDROM drive?), maybe you shouldn’t approve the elevation request.

See larger image
Fig 4. – Elevating the Language Pack Installer. Signed and known by Windows

“So what, exactly, is the protection I’m being granted?” you ask. Well, because only trusted SYSTEM processes can run on the Secure Desktop, it becomes very difficult to spoof what you see on the screen. There are a number of examples of what I’m referring to, but let’s walk through a couple of them so you know what I’m talking about:

  1. Malicious code that spoofs the elevation UI – you can easily imagine that just about anyone with a minimum of Photoshop skills could easily replicate the elevation UI. So you could then imagine that this piece of malicious code downloads itself into your user session when you browse a web page and tries to get you to install it. This code could damage your session and your profile without a full machine install, but it wants a bigger target: your entire machine.

    So, it launches its install code and waits for the elevation UI to pop up. On the user desktop, it could very easily overlay its version of the elevation UI to make it look like something that’s trustworthy. So you take a look, see what appears to be Microsoft Windows Update and decide that, of course, you want to allow it to continue (why wouldn’t you?). That won’t happen when the elevation UI is shown on the Secure Desktop. You are protected from these types of spoofing attacks.

    Remember back to the beginning of this blog entry? This attack is similar to the fake bank rep phoning you up. It’s pretending to be something it’s not because from casual inspection it sure looks like what it claims to be.

  2. Malicious code that spoofs the mouse cursor – Believe it or not, it’s not very difficult to manipulate the mouse cursor and that’s the way it was intended so that you can customize the pointer to whatever fits your style. You can hide the real one and show a fake one just about anywhere on the screen. The net result is that the “hot spot” (i.e. the pixel at which the mouse actions truly work on) may not be where you think the mouse is pointing.

    So how does this spoofing attack work? You hide the real mouse cursor and show a fake one some number of pixels offset to the real one. So now when the user mouses over the elevation UI attempting to cancel it since the malicious software could brazenly announce itself as “I’m gonna own your PC.exe”, what’s really happening is that the hot spot of the mouse is invisibly over the “Allow” button. Click! Not what you thought would happen. This type of attack is also blocked on the Secure Desktop.

    This obviously begs the question of why we don’t provide this type of protection to ALL applications and windows running on the operating system. The full technical details are substantial enough for a future blog post of its own, but in a nutshell since the normal User Desktop is meant for running all types of applications - most of which do not need exceptional privilege to run normally - Windows™ provides a platform where these applications can do whatever is needed to work, including drawing their UI on the screen. We provide several technologies for accomplishing this (e.g. GDI+, DirectX, etc.) and these technologies provide you with the rich visual experiences you see today. But like any tool, these can be misused by software with malicious intent, including unknown malware that may be on your PC. Windows Vista™ contains a number of features aimed to help you keep these off your PC.

    In a perfect world we would love to provide guaranteed input and output so the user sees what their productivity/entertainment/multimedia/etc. applications truly mean for them to see without fearing that a malicious process is messing with it. However, for certain types of UI there are greater needs for this type of protection. That’s why we protect the Logon UI with the secure desktop. Only very special pieces of code should get access to the credentials you use to logon, so we only let you logon or unlock your session from the Secure Desktop.

    However, since User Account Control is all about putting control back into the user’s hands, we have provided a method for allowing the user to control how this prompt occurs. We have added a new policy to the User Account Control policy list (see this previous post on how to access them):

    • User Account Control: Switch to the secure desktop when prompting for elevation

    If this policy is set to be “disabled”, the elevation prompt goes back to the User Desktop as it was in the February CTP. Everyone should note, however, that you will be at risk of exposure from the various attacks I’ve just described should you choose to do this.

    Just like the Logon UI, User Account Control elevation UI should be protected as you review the elevation UI to make your decision on whether or not software should be granted machine-impacting privilege in order to run. Windows™ is doing everything it can to provide you with the most trustworthy information in that dialog, information that it doesn’t even allow the application to provide. The information gathered are from sources that are verifiable whether that is from signed certificates from trustworthy Certificate Authorities all the way down to whatever the binary was named and where it lives in the file system. If we allow a untrusted process to merely paint over that information with whatever it wants or to fool you into clicking something inadvertently, that effort was wasted and you - the user - have no way of making an informed decision. That’s what these prompts are about and that’s why we’ve chosen to put them on the Secure Desktop.