UAC: Desert Topping, or Floor Wax?

Tim Anderson’s ITWriting - Tech writing blog » Why UAC is mostly not a security boundary

Tue, 29 Apr 2008 11:56:01 GMT

PingBack from http://www.itwriting.com/blog/?p=600

re: UAC: Desert Topping, or Floor Wax?

conradoplg — Wed, 30 Apr 2008 06:04:49 GMT

"Of course, you could run as a Standard User under Windows XP, but few people actually did. This is because it was inconvenient: if you wanted to install software or otherwise administer you machine, you had to log out, exiting all your applications and losing all your state, log back in as An Administrator, do your configuration work, log out again, and finally log back in as a Standard User to finally get back to what you were doing."

What? What about runas, makemeadmin, etc?

re: UAC: Desert Topping, or Floor Wax?

crispincowan — Wed, 30 Apr 2008 21:04:47 GMT

Makemeadmin is UAC's grandpa. Runas and makemeadmin are essentially OTS for XP.

However, because they were built without operating system support, they have security and convenience limitations.

Without UIPI, elevated processes on your desktop are vulnerable to shatter attacks, thread injection, etc. Basically, lie-in-wait malware on your desktop could attack your elevated process and get Admin control.

Another major issue is that to do this in XP, you must manually maintain 2 accounts, one of which is administrator and one is not. Technical people should not have a problem with this, but it might confuse end-users to have to have 2 accounts for their *personal* computer.

There is a lot of programs in XP that require administrator, so if you run as a standard user, you would get a lot more issues than you would get UAC prompts on Vista, where some effort was expended to reduce the use of privilege. Vista SP1 further reduced the use of privilege, for even fewer prompts.

And of course, makemeadmin was not bundled with XP, so you had to install it.

So yes, makemeadmin is the same concept, but a lot has been done to make the user experience better.

re: UAC: Desert Topping, or Floor Wax?

crispincowan — Wed, 30 Apr 2008 21:07:26 GMT

P.S. If you are still on XP, and you would like to try makemeadmin, then go get it from Aaron Margosis' blog http://blogs.msdn.com/aaron_margosis/ which is a superb resource for how to run your life as a non-administrator. HIGHLY recommended.

re: UAC: Desert Topping, or Floor Wax?

Nick42 — Thu, 01 May 2008 04:14:13 GMT

This blog post was linked from this article: http://neosmart.net/blog/2008/ireboot-and-working-around-uac-limitations/

I was wondering if you had any comments on the issue/workaround expressed in the article. Specifically, the fact the security changes with UAC require ISV's to write custom LPC/RPC surfaces for services running as LocalSystem to perform admin actions from Shell inputs (eg: triggered from tray icons). Doesn't the lack of a standard, secure, supported, native-code accessible, recommended RPC interface, coupled with the Shell changes, almost guarantee a worse problem going forward as various ISV's are forced to deploy custom surfaces bypassing the UAC security barrier? Any thoughts?

re: UAC: Desert Topping, or Floor Wax?

crispincowan — Thu, 01 May 2008 08:17:19 GMT

I stand by the *broad* criticism that this "attack" has received. The claim that they have bypassed UAC is completely bogus:

http://neosmart.net/blog/2008/ireboot-and-working-around-uac-limitations/#comment-148146

http://neosmart.net/blog/2008/ireboot-and-working-around-uac-limitations/#comment-148148

http://neosmart.net/blog/2008/ireboot-and-working-around-uac-limitations/#comment-148152

http://developers.slashdot.org/comments.pl?sid=536078&cid=23217234

The architecture that i-Reboot implemented appears to be precisely the recommended approach when your application needs privilege: separate the priviliged part away from the rest of the application. This enhances security, because it reduce the attack surface that is running with Administrator privilige.

The authors seem to be very confused, and taking things just a tad personally. They assume that UAC has a design goal of preventing a program from being priviliged and auto-running on startup, frustrating their work. This is not the case; rather, UAC does not provide a mechanism to grant Administrator privilege to a program file because to do so represents a security risk that we don't want to expose. It does let you install a privilged service because that is less exposed, and that is precisely what they did. They didn't bypass anything, they just used it correctly.

At least I hope they did. Their privileged service is now part of the operating system's TCB (Trusted Computing Base). If there are any vulnerabilities in the i-Reboot service, then malware can exploit it to gain Administrator privilege. Be careful implementing privileged services, as they have to measure up to that "perfect software" thing.

re: UAC: Desert Topping, or Floor Wax?

Morten Mertner — Thu, 01 May 2008 14:24:32 GMT

Couldn't TPM be used to ensure that the OS knows when the user clicks on something, and this information in turn be used to silently authorize UAC prompts for those cases?

Call it a Windows UAC Popup Blocker, since it's very similar to the technique successfully applied by browsers.

I'd also like to criticize UAC (for AAM) as being a pointless nuisance. At the very least it gives a false impression of security to people running as an administrator, which generally should be a much harder choice to make in the first place.

re: UAC: Desert Topping, or Floor Wax?

Nick42 — Thu, 01 May 2008 21:28:05 GMT

I don't think the authors are confused, at least those posting who understand the security mechanisms. I think everybody is on the same page: they split the functionality, and implemented a custom RPC to a TCB service. I think the only consternation among the informed participants is the security considerations implied by the addition of many new custom RPC's into the TCB, rather than an alternative (theoretical) supported RPC for communicating between the part of you application which now resides in the TCB, and the part which must run in normal-user space.

By forcing the creating on custom RPC's into the TCB, MS has effectively expanded the TCB to include any ISV's who deploy any application which wants to perform admin-required actions without annoying prompts, and also interact with the user. Moreover, running applications as a normal user now offers less protection than in pre-Vista Windows versions, due to the substantially expanded and less tested TCB RPC surface. I'm not sure everyone would consider that an increase in overall security.

re: UAC: Desert Topping, or Floor Wax?

crispincowan — Thu, 01 May 2008 21:45:54 GMT

Morten; yes you could use TPM, and a whole chain of software up through the stack to the graphics card and the mouse, to prove that a user really did click "that". The problem then becomes "what did you mean by 'that'?"

Fundamentally, everything you do on your computer is a consequence of some kind of user action, which causesd a chain of software events to occur. It really is a very long chain of events; the only thing you directly cause to happen by clicking the mouse button is a circuit closes, some sensors go off, and an interrupt is raised to the CPU. Then some interrupt handling software goes off, queues an event that a mouse has been clicked, that goes into the .... you get the idea.

My point being, even with a very direct click of a mouse on an install button, your "action" is quite indirect. In the case of malware, the path is only slightly more indirect. In fact, it may not be any more indirect than an actual deliberate user action, it is just unexpected.

While it is theoretically possible to crypto sign the entire chain of software from the TPM through the boot device, the mouse the window system, the graphics card, everything between your finger and the silicon, the management of maintaining certificates for all of that is awful, and I'm not convinced that when you are done, it really means what you want it to mean.

Instead, what UAC does is pop the the secure desktop (that grey-out look) which shuts out all other software, and asks you if you really meant to do this action that requires privilege. I really don't think there is any other way to do it.

What we can improve on is to do it a lot less often. We do that by cleverly adapting to what users really do, automating some privileged stuff by putting more software inside the TCB, and changing other software so that it no longer has to trust the TCB.

Meanwhile, if you really don't want to see the prompts, and you don't mind the implicit compromise in security, go ahead and use Administrator in Silent Mode.

re: UAC: Desert Topping, or Floor Wax?

crispincowan — Thu, 01 May 2008 21:53:08 GMT

Nick; setting aside interpreting whatever the authors of i-Reboot meant, I'm not sure I understand your point.

Any ISV that needs to deploy privileged software necessarily expands the TCB to include their privileged software. This is always the case, on Windows, Mac OSX, Linux, etc.: software that has administrative privilege must be considered part of the TCB. So we are not getting out of ISVs expanding the TCB.

Perhaps your issue is with respect to the RPC protocols used to communicate with Administrator services in Windows? What is the issue here?

With respect to the TCB attack surface exposed to users: it is true that AAM on Vista offers a larger attack surface than Standard User on XP. However, (I suspect) that the attack surface for a true Standard User in Vista is considerably smaller than for a Standard User in XP, just because a lot of attack surface analysis was done in Vista to minimize this.

It is true that installing 3rd party trusted software in Vista does expand the TCB attack surface by providing exposed Administrator services, but I don't see this as a degredation vs. XP. For XP to do precisely the same thing, they would have to also install an Administrator Service. More likely, XP code would just assume that you are running the desktop application as Administrator and not do any privilege separation at all.

Sorry if I've missed your point.

re: UAC: Desert Topping, or Floor Wax?

Nick42 — Thu, 01 May 2008 22:26:25 GMT

A specific example, to show what I mean.

Say you have a simple app that does some admin task (eg: periodic virus scan). You have implemented it as a service, and expose a tray icon to allow the active user to pause the scan for some period of time. You have installed the service running as LocalSystem, with Interact with Desktop. Your TCB surface, in this case, is the Windows messages sent to your tray icon (assuming the user is not already in the TCB).

In Vista, this needs to be changed. I need to have a user-mode app to interact with the Shell, and my TCB service. The TCB service needs a custom RPC which is not allowed to be Windows messages, or any other easily understood and well-tested RPC; I must make my own, using something like sockets, named pipes, shared memory, or the RPC support. Moreover, this RPC may be exposed to all users, not just the desktop user, and may be remotable if I'm not careful. There may also be timing issues, or other things I have not considered.

Yes, my concern is primarily with the RPC protocols. It always seemed silly to me for MS to go through all the work reducing the RPC surface on built-in services, and then force ISV's to expand it with custom RPC's. Hope that helps clarify what I meant.

re: UAC: Desert Topping, or Floor Wax?

crispincowan — Wed, 07 May 2008 03:56:47 GMT

So your concern is about the attack surface security of the RPC protocol to trusted services. Lets consider the XP alternative: your trusted service was displaying an icon in the tray. This icon shares the desktop with the user, which means that any user process can send messages to your privileged service. This is what makes the attack surface for a privileged service with a desktop display icon rather large, and why Vista is an improvement.

Note that if you wnat user interaction with a privileged service, then you inevitably are going to have *some* attack surface. The fussing is over what that surface looks like, and how to minimize and harden it.

re: UAC: Desert Topping, or Floor Wax?

alias33 — Sat, 16 Aug 2008 09:24:57 GMT

Did I just read UAC being referred to as a convenience feature?! You've used Vista for longer than 10 minutes at a time, right?

re: UAC: Desert Topping, or Floor Wax?

VistaLover — Thu, 21 Aug 2008 05:21:52 GMT

Alias33, why don't you read the whole article before jumping into kneejerk-attack-MS mode...

re: UAC: Desert Topping, or Floor Wax?

Alun Jones — Mon, 13 Oct 2008 23:25:10 GMT

Describing Vista's UAC as a "convenience feature" underlies why it's loved by some, reviled by others.

If your aim is to run as a restricted user as much as possible, and switch into administration mode only when you have to do an admin task, after which you remain restricted, then UAC is a convenience. It allows you to quickly switch from restricted to admin and back, far quicker and easier than a "Switch User" or logout/logon sequence that is your alternative.

If your aim is to do administrative tasks along with other uses of your computer, UAC is an inconvenience.

If all your software insists that you be an admin in order to run it, UAC is an inconvenience.

Quite frankly, we should have been at a point a decade ago such that most users never/rarely have to be admin - games should not require you be an admin; office productivity tools shouldn't require it; it's embarrassing to me as a software developer to see that there are many popular programs out there that assume that we're still living in a Windows 98 world, where all users are the same user, and that user is an administrator.