User Account Control Prompts on the Secure Desktop

re: User Account Control Prompts on the Secure Desktop

Greg Merideth — Thu, 04 May 2006 05:12:50 GMT

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?

re: User Account Control Prompts on the Secure Desktop

MichaelGiagnocavo — Thu, 04 May 2006 05:39:21 GMT

Great article -- I have high hopes for this.

Two questions:
1 - Is Microsoft still going to rely on the current abused PKI to determine publisher information? Showing a "nicer" box just cause someone signed it by one of the "trusted" CAs doesn't do much (ActiveX and IE) -- not to mention the default trusted CA list is enormous and includes CAs that most users (in the USA) would never trust. So will Microsoft have a more restrictive set of CAs for the purposes of downgrading warnings?

2 - What's to stop a desktop app from spoofing the Secure Desktop UI? Isn't it just screenshot + 50% black + centered nifty dialog box?

Thanks!

Windows Observer » Blog Archive » Everything You Wanted to Know About User Account Control

Thu, 04 May 2006 05:41:30 GMT

PingBack from http://www.windowsobserver.com/2006/05/03/everything-you-wanted-to-know-about-user-account-control/

re: User Account Control Prompts on the Secure Desktop

mgm — Thu, 04 May 2006 05:50:06 GMT

Will the UAC dialog be visible if you have remote desktop-ed into the PC?

re: User Account Control Prompts on the Secure Desktop

Matt — Thu, 04 May 2006 05:51:57 GMT

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.

re: User Account Control Prompts on the Secure Desktop

Matt — Thu, 04 May 2006 05:54:44 GMT

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 appearing

re: User Account Control Prompts on the Secure Desktop

MichaelGiagnocavo — Thu, 04 May 2006 06:03:00 GMT

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.

re: User Account Control Prompts on the Secure Desktop

Adam — Thu, 04 May 2006 06:03:38 GMT

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.

Adam

re: User Account Control Prompts on the Secure Desktop

Ian Reandeau — Thu, 04 May 2006 06:41:53 GMT

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.

New User Access Control Articles

Sidebar Geek — Thu, 04 May 2006 06:45:38 GMT

The User Access Control (UAC) Blog talks about the Application Compatibility Toolkit 5.0 that's coming....

re: User Account Control Prompts on the Secure Desktop

Nicholas — Thu, 04 May 2006 07:17:33 GMT

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.

re: User Account Control Prompts on the Secure Desktop

Paul — Thu, 04 May 2006 15:17:41 GMT

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?

re: User Account Control Prompts on the Secure Desktop

JohnGalt — Thu, 04 May 2006 16:46:29 GMT

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.

re: User Account Control Prompts on the Secure Desktop

Alun Jones — Thu, 04 May 2006 19:01:19 GMT

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.

re: User Account Control Prompts on the Secure Desktop

Impressed Observer — Thu, 04 May 2006 23:41:28 GMT

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

re: User Account Control Prompts on the Secure Desktop

compugab — Fri, 05 May 2006 00:34:35 GMT

Thanks for the great post... Keep them coming

re: User Account Control Prompts on the Secure Desktop

apankrat — Fri, 05 May 2006 02:12:53 GMT

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 ?

re: User Account Control Prompts on the Secure Desktop

zzz — Fri, 05 May 2006 08:06:26 GMT

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.

re: User Account Control Prompts on the Secure Desktop

Hello1024 — Fri, 05 May 2006 20:57:24 GMT

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

re: User Account Control Prompts on the Secure Desktop

RMA — Sat, 06 May 2006 00:09:08 GMT

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.

.: Utakz’ Blog :. » Blog Archive » Windows Vista Beta 2 Milestone Build 5381.*!

Sat, 06 May 2006 01:32:11 GMT

PingBack from http://blog.utaks.net/?p=12

re: User Account Control Prompts on the Secure Desktop

Tom — Sat, 06 May 2006 02:38:16 GMT

In the corner of the UAC pictures, it says beta testing purposes build 5421, when beta 2 is supposed to be 5381

re: User Account Control Prompts on the Secure Desktop

prismX — Sat, 06 May 2006 15:55:52 GMT

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.

Window Vista 5381(Beta 2 escrow) Now Available on Connect

Josh's Windows Weblog — Sat, 06 May 2006 22:36:40 GMT

Microsoft early this morning released an early copy of Windows Vista 5381 to its Connect web site for...

re: User Account Control Prompts on the Secure Desktop

PatriotB — Sun, 07 May 2006 04:30:18 GMT

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

re: User Account Control Prompts on the Secure Desktop

apankrat — Mon, 08 May 2006 00:09:27 GMT

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

re: User Account Control Prompts on the Secure Desktop

PatriotB — Wed, 10 May 2006 05:33:41 GMT

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?

re: User Account Control Prompts on the Secure Desktop

User Account Control Team — Mon, 15 May 2006 21:11:37 GMT

The screenshots have been updated with higher resolutions.

-Jenn

re: User Account Control Prompts on the Secure Desktop

Jim — Mon, 15 May 2006 21:58:45 GMT

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,
Jim

re: User Account Control Prompts on the Secure Desktop

Joe — Fri, 19 May 2006 04:44:22 GMT

Can we have more settings in the Control panel as well as Group policy?

re: User Account Control Prompts on the Secure Desktop

BryanM — Fri, 19 May 2006 19:50:44 GMT

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?

re: User Account Control Prompts on the Secure Desktop

j.allen — Fri, 19 May 2006 20:37:23 GMT

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.

-Jenn

re: User Account Control Prompts on the Secure Desktop

David Hopwood — Sat, 20 May 2006 06:39:26 GMT

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

re: User Account Control Prompts on the Secure Desktop

Alex Heaton (MS) — Sat, 20 May 2006 08:29:33 GMT

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

re: User Account Control Prompts on the Secure Desktop

Michael Giagnocavo — Sat, 20 May 2006 17:39:09 GMT

"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?

re: User Account Control Prompts on the Secure Desktop

David Hopwood — Sat, 20 May 2006 19:00:11 GMT

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.

re: User Account Control Prompts on the Secure Desktop

Michael Giagnocavo — Sun, 21 May 2006 02:59:59 GMT

Not to mention that signing is nearly ineffective because of the plethora of CAs, poor policy, etc. (See ActiveX signing...)

re: User Account Control Prompts on the Secure Desktop

David Hopwood — Sun, 21 May 2006 06:25:44 GMT

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.

re: User Account Control Prompts on the Secure Desktop

j.allen — Mon, 22 May 2006 22:38:24 GMT

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.

-Jenn

re: User Account Control Prompts on the Secure Desktop

j.allen — Mon, 22 May 2006 23:42:22 GMT

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.

re: User Account Control Prompts on the Secure Desktop

MichaelGiagnocavo — Tue, 23 May 2006 00:14:16 GMT

Oh, in that case, right on! I figured it'd have to be that way, but someone indicated to the contrary...

re: User Account Control Prompts on the Secure Desktop

Thomas — Tue, 23 May 2006 10:01:32 GMT

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.

Tom

Windows Vista Beta 2 looks promising

TechBlog — Tue, 23 May 2006 19:00:22 GMT

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

LUA with UAC vs Least Privilege

Dana Epp's ramblings at the Sanctuary — Wed, 24 May 2006 01:03:18 GMT

So today I was talking with Eric about my previous post Microsoft... Eat your own UAC dogfood already!, when he asked me if running as an admin on Vista with LUA enabled count as least privilege in my mind. (I am paraphrasing... pipe up if I misunderstood

re: User Account Control Prompts on the Secure Desktop

Maurits — Fri, 02 Jun 2006 22:15:35 GMT

The mouse "hot spot" attack is an interesting one. I'm glad I always press "Esc" or "Enter"!

If the user is careful, though, they should see the "OK" button depress when they mousedown.

With the mouse button still down, they can move the hotspot (not the pointer) out of the button area, then release the button...

... and no click event will fire, right?

re: User Account Control Prompts on the Secure Desktop

David Hopwood — Wed, 07 Jun 2006 02:32:30 GMT

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?

Prince’s Blog » Blog Archive » Vista Build 5421 Revealed!!

Prince’s Blog » Blog Archive » Vista Build 5421 Revealed!! — Mon, 12 Jun 2006 19:24:55 GMT

PingBack from http://plex.wordpress.com/2006/05/05/vista-build-5421-revealed/

What's New in Beta 2? - Group Policy Updates

UACBlog — Wed, 21 Jun 2006 19:46:44 GMT

Since Beta 1, the UAC policies have adapted to address customer recommendations, enhance security, and...

re: User Account Control Prompts on the Secure Desktop

Greg — Thu, 06 Jul 2006 05:41:07 GMT

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

UAC Improvements in Release Candidate 1 (RC1) and Video

UACBlog — Wed, 06 Sep 2006 02:16:47 GMT

We’d like to thank all of the Windows Vista beta testers for using and giving us feedback on User Account...

re: User Account Control Prompts on the Secure Desktop

tester — Sat, 09 Sep 2006 13:58:14 GMT

I hope it will be the best product ever.

<a href="http://google.com">Google</a>

Jean’s note » Windows Vista ????????????

Jean’s note » Windows Vista ???????????? — Sat, 28 Oct 2006 12:37:02 GMT

PingBack from http://www.digito.com.tw/~jeanliao/note/?p=88

Symantec Anti-UAC Product is a Very Bad Idea

Robert McLaws: Windows Vista Edition — Wed, 10 Jan 2007 21:48:49 GMT

Symantec seems to think that Vista's User Account Control prompts people too much, and wants to make

Windows Vista Download - » Blog Archive » Symantec Anti-UAC Product is a Very Bad Idea

Fri, 12 Jan 2007 05:05:15 GMT

PingBack from http://www.windowsvistadownload.co.uk/?p=61

Identity Management and CardSpace

João "jota" Martins — Thu, 18 Jan 2007 02:08:27 GMT

Identity Management is not one of my priorities , but it's a subject I've been interested about for sometime,

Symantec Anti-UAC Product is a Very Bad Idea at Vistalogy

Symantec Anti-UAC Product is a Very Bad Idea at Vistalogy — Thu, 18 Jan 2007 12:18:26 GMT

PingBack from http://www.vistalogy.com/2007/01/18/symantec-anti-uac-product-is-a-very-bad-idea/

re: User Account Control Prompts on the Secure Desktop

cass — Thu, 08 Mar 2007 17:41:10 GMT

@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!