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:
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.
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.
-Jim
Comments
Anonymous
May 03, 2006
So...we as administrators have to bounce around to hundreds of desktops every time something needs to install elevated or give the end-user, an administrator password. If the end-user now has the password they can install anything they want at higher privleges at a whim?
If we don't provide the admin passwords we will need to physically be at the computer, even roaming laptop users who may be at a clients site installing software, to put our passwords in?Anonymous
May 03, 2006
The comment has been removedAnonymous
May 03, 2006
PingBack from http://www.windowsobserver.com/2006/05/03/everything-you-wanted-to-know-about-user-account-control/Anonymous
May 03, 2006
Will the UAC dialog be visible if you have remote desktop-ed into the PC?Anonymous
May 03, 2006
Greg,
There's nothing in this article that suggests remote tools (e.g. SMS Remote Control) won't work so you're no worse off.
And, from memory, all this elevation stuff defaults to disabled when you join a domain.
You're no worse off and you could have done some basic research before starting off on an ill informed rant.Anonymous
May 03, 2006
Michael,
I think the point is you can spoof the UI but cannot spoof the effect (ie get higher privileges).
If the spoofed UI were to try to get priveleges it would result in the genuine ui appearingAnonymous
May 03, 2006
Matt,
Well, you can't escalate, but you could ask for someone's password, then use that in your own code to escalate (or something).... right? Since the user thinks it's secure, they have no qualms about typing in their password.Anonymous
May 03, 2006
I'd love to hear more about what user testing you've done around this. Ideally, in a context of "security as a secondary task," because I think that's the most interesting test.
AdamAnonymous
May 03, 2006
mgm: Will the UAC dialog be visible if you have remote desktop-ed into the PC?
Yes, it looks the same over TS as it does when you are on the local machine.Anonymous
May 03, 2006
The User Access Control (UAC) Blog talks about the Application Compatibility Toolkit 5.0 that's coming....Anonymous
May 03, 2006
This is sweet, and definitely a step in the right direction. Force users to be 100% aware of the risk/action they are taking before they take it.Anonymous
May 04, 2006
Will later builds of Vista enable the secure desktop version of user account control to be displayed using glass rather than droping back to GDI as show in the screenshots?Anonymous
May 04, 2006
As others said, get rid of the UAC prompt if I'm already logged in as an administrator and I'm Happy. Otherwise you've guarenteed that I won't be using Vista.Anonymous
May 04, 2006
JohnGalt - you can disable this prompting through a policy - but then, the point is that you won't be aware of when you're running as admin unnecessarily, which is the point of this approach.
Figure 3 looks like a bad example to have chosen - there is no indication of the window that caused the dialog to appear. What's going to happen for users is they'll have a big window on their desktop, and a small window, or windowless application, will ask for privileges - they'll associate the privilege request with the application they're working on, and approve it, rather than realising that it's a separate process that's begging for rights.Anonymous
May 04, 2006
All very well and impressive but a thought just crossed my mind...
Suppose you were epileptic or sensitive to sudden flashing images or sudden changes in light, would the cure be to work in a well lit room?
And I am aware of the time taken in coding etc... but would it be possible to get the background shade in different degrees of dark intensity?
Just in case, I DO think that this is a step in the right direction :)Anonymous
May 04, 2006
Thanks for the great post... Keep them comingAnonymous
May 04, 2006
So what does prevent me from taking a screenshot of a desktop, dimming it, placing in a topmost window and faking UAC dialog on top of it ?Anonymous
May 04, 2006
Yeah I do not quite get this. It still seems trivial to spoof an identically acting screen that asks for admin password. Wouldn't the safest be to just not ask for a password in any situation?
If you ask for a pass then it must be programmatically impossible to use a password to gain elevation. And I seriously doubt it is..
Also I Demand that there is a option to "By default always show Details" for all these dialogs that hide details. I bet that in many cases the devil is in the details and need to see the information to make a decision.Anonymous
May 05, 2006
I don't know if this is just an issue with vista and old vista builds, but in my experience switching desktops seems to mean a screen mode switch, and redrawing the entire screen, and on low-ram systems this also takes lot of paging as well.
Is this still the case? - I don't want to have to wait 3 secs whenever the secure desktop UI comes up or is "OK'd". With the current vista feb ctp, the secure UI switches the screen off (powered down) for about 5 secs before appearing. (And then there's the screens "warm up" toime to wait as well) - although I suspect thats due to another issue with the glass and the "fade to gray".Anonymous
May 05, 2006
You know the current bug where a glass desk top goes black and then paints grey - unlike a non glass desk top which just nicely greys surely needs fixing. This is reported and voted on by many people - but microsoft said it wont be fixed. it looks ugly to blank the screen and re-paint - especially with glass enabled machines.Anonymous
May 05, 2006
PingBack from http://blog.utaks.net/?p=12Anonymous
May 05, 2006
In the corner of the UAC pictures, it says beta testing purposes build 5421, when beta 2 is supposed to be 5381Anonymous
May 06, 2006
Dear Jim
This is very nice article, but I have some issues with implementation os UAC:
1. Dimming of UI may lead to a lot of problems in case of buggy drivers and it will not be rare considering a huge amount of video cards supported by Windows, but this is only technical issue
2. I do not understand why is not enough to ask user enter password at any case of system level access, as neither mouse can feed password... It works very well on Linux and MacOSX, why should it make mad Windows user???
and if anyway some Windows users are so nervous, you could add some tweaks to setting of UAC with default and advanced options, such as a) request password b) request password for unknown applications and for "known" (so dimming ...) just allow c) disable UAC d) deny user to install. The last would protect the system even if an user have the admin password. And here the third issue follows:
3) Setting lock: In MacOSX there is an additional level of security: locking of the setting. I suppose it is very well approach despite an implementation is not so correct as it asks the same admin's password. I suppose there should additional setting unlock password that could be different from the admin password too, and this could prevent setting changes if admin account is open and accessible physically for anybody.
I understand that this creates some annoying problems, but at least you have to give these choices to people and let them decide to use or not to use.
And an additional issue:
Why is still optional to set password for admin? If the first user created during the OS setup is of admin group, why the built-in administrator account is not disable at least until strong password is set for it???
If somebody does not need this level of security he could change this setting from easy control panel access without policy changes.Anonymous
May 06, 2006
Microsoft early this morning released an early copy of Windows Vista 5381 to its Connect web site for...Anonymous
May 06, 2006
"So what does prevent me from taking a screenshot of a desktop, dimming it, placing in a topmost window and faking UAC dialog on top of it ?"
Nothing, the same as how in XP, there's nothing stopping you from spoofing the RunAs credential dialog. There's really no way to prevent this on any operating system. Except maybe by requiring Ctrl+Alt+Delete, like Windows has at logon.
The key point is that, even if a rogue program gets your administrative password, it can only log you on and do "standard" user stuff with it; it can't do anything "administrative" with it--as soon as it would try, the "true" Consent UI would appear and need to be okayed first.
At least that's how I see it.Anonymous
May 07, 2006
>> The key point is that, even if a rogue program gets your administrative password, it can only log you on and do "standard" user stuff with it; it can't do anything "administrative" with it--as soon as it would try, the "true" Consent UI would appear and need to be okayed first.
Can I ask where you dugg up this "key point" ?
It means drastic departure from existing access control model. Have a look at LogonUser and CreateProcessAsUser API and try to think what will happen for example to the system service that uses these functions and runs on an unattended machine.Anonymous
May 09, 2006
What I mean by that, is that if malware gets ahold of your user name and password, it can log you on, but that logon will now be a "standard user", not an "administrator". If it tries to do anything administrative, it will either 1) fail, or 2) cause an elevation prompt to appear. Yes, it could wreak havoc on your account (delete your files, probably change your password and lock you out), but it couldn't do anything administrative like create/delete other accounts, delete other users' files, delete system files, or install (systemwide) programs.
At least that's what I believe to be true, based on what I've read. Could one of the bloggers confirm this?Anonymous
May 15, 2006
The screenshots have been updated with higher resolutions.
-JennAnonymous
May 15, 2006
Sorry to be late on the comments responses, but I was out of the office last week and am now just coming up for air.
To answer some of the questions, this User Experience is still spoofable, as some of you have pointed out. However, malware does not gain elevated privileges by spoofing the UI.
We are aware that there are currently some drivers who handle the desktop switch better than others. We have teams in Windows working to get the drivers to handle this better across the board. Our goal is to have this switch look very fast and seamless by the time we ship.
The elevation UI will appear UX Themed as opposed to AERO (i.e. Glass) themed. This is due to some limitations we have on graphics rendering technologies on the secure desktop. We are aware of this and are working towards making this more elegant in a future version of Windows.
Elevation UI with no parent window - This should be one of the hints that should make users pay attention more closely. We are working to get all of the Windows elevations to come with a parent window. If you see an elevation - especially one with an "orange" banded dialog - that appears with no parent, you should consider more carefully what is asking you for administrative privilege.
Keep the questions coming!
Thanks,
JimAnonymous
May 18, 2006
Can we have more settings in the Control panel as well as Group policy?Anonymous
May 19, 2006
Is it possible, as an Administrator, to configure and customize which activities and actions have the UAC shield and throw up a permission dialog? If not, will this be a feature at release?Anonymous
May 19, 2006
Joe: Any specific recommendations for settings?
BryanM: No, admins cannot configure which tasks will require elevation (consent or credential). By default, application installations that are not per-user and core administrative tasks require elevation. Many teams have done a lot of work to limit the tasks that require elevation. For instance, a standard user can now configure the time zone, which will make working remotely as a standard user much easier. Standard users can now also edit the display settings without elevating. Another team member is putting together a post about this type of UAC prompt reduction. The elevation prompt is displayed to the user to ensure that no administrative action is approved without the user knowing about it.
More answers and responses are coming soon.
-JennAnonymous
May 19, 2006
PatriotB wrote: "What I mean by that, is that if malware gets ahold of your user name and password, it can log you on, but that logon will now be a "standard user", not an "administrator". If it tries to do anything administrative, it will either 1) fail, or 2) cause an elevation prompt to appear."
You're mistaken -- UAC cannot stop a process that knows the administrator password from acting as an adminstrator. Once it knows the password, a process running in a standard privilege account can use CreateProcessWithLogonW() (the same API that is used to implement "Run As"), to run a subprocess with administrator privileges, which will not be subject to UAC.
Jim wrote: "If you see an elevation - especially one with an "orange" banded dialog - that appears with no parent, you should consider more carefully what is asking you for administrative privilege."
This seems to have completely missed Alun Jones' point: "What's going to happen for users is they'll have a big window on their desktop, and a small window, or windowless application, will ask for privileges - they'll associate the privilege request with the application they're working on, and approve it, rather than realising that it's a separate process that's begging for rights."Anonymous
May 19, 2006
Regarding this comment from David, "What's going to happen for users is they'll have a big window on their desktop..."
In the Beta 2 version of the dialogs. If it is a valid signed program we pick up the icon and and app name so the user knows what is prompting. If it unsigned we show that orange dialog that includes the file name of the program the program that is actually requesting the privelages--in this case the user can see it is the small hidden one, not the big one the user is using.
Hope that helps. - AlexAnonymous
May 20, 2006
"UAC cannot stop a process that knows the administrator password..."
-- Then again, where's the protection/value against some app just spoofing secure desktop, getting the admin password, and going to town?Anonymous
May 20, 2006
Alex Heaton: "If it is a valid signed program we pick up the icon and and app name so the user knows what is prompting."
This might work if almost all programs are signed. But in practice, many programs are not going to be signed, and so users will frequently have to accept elevations from unsigned programs.
Michael Giagnocavo: that was exactly my point. It is possible to provide an UI that prevents spoofing (by reserving a part of the screen that is always controlled by the system, e.g. see http://srl.cs.jhu.edu/courses/600.439/shap04windowsystem.pdf), but Vista doesn't do that.Anonymous
May 20, 2006
Not to mention that signing is nearly ineffective because of the plethora of CAs, poor policy, etc. (See ActiveX signing...)Anonymous
May 20, 2006
Exactly. There are really at least two separate problems that Microsoft are conflating by basing the elevation prompts on signatures:
1. When I install a piece of software, how do I know that it is an authentic copy of an application from some source that I know by reputation?
2. How do I know which of the installed applications controls which parts of the user interface, or is being referred to by a particular security-relevant UI? (Note that knowing which windows are controlled by the system is a special case of this.)
Signatures at best address part of the first problem, and do it rather poorly, at least in the context of a CA-based PKI (as you've pointed out, and as Bruce Schneier, Carl Ellison and others have written about).
The second of these problems is the more important one for the design of elevation prompts and other security-relevant UI. It isn't necessary to use signatures to solve it: if an OS can't separate applications from each other and keep track of which is which by use of file system permissions, then signatures won't help.
For an alternative approach to the second problem, google CapDesk. It has the user assign a name and icon to each app on installation, so that they can choose names/icons that are visibly distinct, without having to rely on the worst-case review procedure of any CA on some long list.Anonymous
May 22, 2006
David Hopwood:
"You're mistaken -- UAC cannot stop a process that knows the administrator password from acting as an adminstrator. Once it knows the password, a process running in a standard privilege account can use CreateProcessWithLogonW() (the same API that is used to implement "Run As"), to run a subprocess with administrator privileges, which will not be subject to UAC."
CreateProcessWithLogonW() is subject to the UAC functionality and will create the new process with a "UAC" access token.
-JennAnonymous
May 22, 2006
Answers from Jonathan Schwartz--
MichaelGiagnocavo: "Well, you can't escalate, but you could ask for someone's password, then use that in your own code to escalate (or something).... right? Since the user thinks it's secure, they have no qualms about typing in their password."
Nope -- we've blocked programmatic elevation at the API level (and at the network level).
zzz: "Yeah I do not quite get this. It still seems trivial to spoof an identically acting screen that asks for admin password. Wouldn't the safest be to just not ask for a password in any situation?"
Actually, it is programmatically impossible to use a password to elevate now (short of running as SYSTEM). If there end up being any holes here, that's a bug and we'd definitely like to hear about it :)
PatriotB: "At least that's what I believe to be true, based on what I've read. Could one of the bloggers confirm this?"
Yes, you're correct.Anonymous
May 22, 2006
Oh, in that case, right on! I figured it'd have to be that way, but someone indicated to the contrary...Anonymous
May 22, 2006
Sorry guys, really don't want to flame ... but Gnome & KDE, the two most popular Linux GUIs have such a feature for ... well for at least a few years now. But it can even be done better:
In Gnome, when there's an administrator (=root) user with a password set, then any action that needs admin/root priviliges asks for the admin/root password. But, if the unprivileged user is also in the "admin" or "wheel" group (depends on the distro) and you're working as an unprivileged user, then you are asked for your password if you want to alter the system. This is really nice, as you can have all users run unprivileged, and only you can do admin tasks by typing the admin password, but if you also have an technically advanced user, you add him to the admin group, so he still runs unprivileged, but he can also do admin tasks by entering his password.
TomAnonymous
May 23, 2006
Late Monday afternoon at the Windows Vista Reviewers Workshop, I got my hands on Beta 2. It'll be a day or two before I'll have time to install it, but from what I've seen during a day of demo and...Anonymous
May 23, 2006
The comment has been removedAnonymous
June 02, 2006
The comment has been removedAnonymous
June 06, 2006
J. Allen wrote:
"CreateProcessWithLogonW() is subject to the UAC functionality and will create the new process with a "UAC" access token."
I find it hard to believe that there is no way for a process that knows the Administrator password to get effective admin privileges without an elevation prompt. What about network access (e.g. SMB if "File and print sharing" is enabled), for example?Anonymous
June 12, 2006
PingBack from http://plex.wordpress.com/2006/05/05/vista-build-5421-revealed/Anonymous
June 21, 2006
Since Beta 1, the UAC policies have adapted to address customer recommendations, enhance security, and...Anonymous
July 05, 2006
>You're no worse off and you could have done
>some basic research before starting off on
>an ill informed rant.
> Matt
Actually Matt, that question was posted during the live webcast, before any part of this blog was posted. When trying to be condescending or sanctimonious, do some basic research before posting ill informed replies.Anonymous
September 05, 2006
We’d like to thank all of the Windows Vista beta testers for using and giving us feedback on User Account...Anonymous
September 08, 2006
I hope it will be the best product ever.
<a href="http://google.com">Google</a>Anonymous
October 27, 2006
PingBack from http://www.digito.com.tw/~jeanliao/note/?p=88Anonymous
January 10, 2007
Symantec seems to think that Vista's User Account Control prompts people too much, and wants to makeAnonymous
January 11, 2007
The comment has been removedAnonymous
January 17, 2007
Identity Management is not one of my priorities , but it's a subject I've been interested about for sometime,Anonymous
January 17, 2007
PingBack from http://www.vistalogy.com/2007/01/18/symantec-anti-uac-product-is-a-very-bad-idea/Anonymous
March 08, 2007
@Thomas: sorry but, the linux is unsafe because each user is able to alter the system with own password and this is bad in a multiusers enviroment!