ManipUni said:

I think I'm starting to side with Microsoft on this issue. The more I look at UAC the more I realize that the entire thing is a waste of time with or without the whitelist. All the whitelist does is draw attention to a large hole that already exists in the way UAC functions. It *might* make automating escalation slightly easier, but I would say it is a relatively easy thing to do either way.

My advice to Windows 7 (and Vista) users now is, don't run as an administrator account. UAC will offer no protection. Run as a user and create an administrator account to login using the UAC prompt. That gives you UAC with real process isolation.

The more I look at UAC the more I realize that the entire thing is a waste of time with or without the whitelist.

Run as a user and create an administrator account to login using the UAC prompt.

Prompt-spoofing can be done from standard user accounts. e.g. You want to open an elevated command prompt. Something's waiting for you to click that button and gets there first. All you see is a UAC dialog saying cmd.exe from Microsoft is about to be run. You don't know it's being run with different arguments, so you type your password in and by the time you see the second UAC prompt it's too late.

(Even code-injection could also be done from standard user accounts, although it is far, far more difficult. If someone spends enough time analysing the target process they could do it, though. e.g. You trigger an elevation in Explorer. Something's waiting for you to do that and finds the elevated IFileOperation object pointer in Explorer's memory and starts sending commands to it. Very, very difficult but not impossible.)

Even if you don't use elevation at all, and use fast user switching instead, things can go wrong. If you decide to browse the web using standard user for security, how do you know that an unsigned exe you download hasn't been changed by malware between you saving it to disk and you switching to the admin account to run the installer?

So there are issues even with standard user elevation and the real security boundary. That's life. It doesn't mean we should throw our hands up and ignore all security issues with standard user accounts, does it? So why are we doing that with limited-admin accounts when they are still what the majority of non-business users will use?

It all boils down to making things difficult enough that they will not be exploited quickly or often.

What the default settings are, and what users will actually put up with, also cannot be ignored.

You can say people should change the defaults to be more secure but it's about as likely to happen for most users as people changing to Linux to be more secure.

You can say that people should put up with the hassle of typing in a password five times in a row because they needed to move some data around in Program Files, but that's about as likely to happen as people disassembling every program they download to check for malicious code.

The situation we're in now is that the default settings have been made easy to bypass. That's not good.

Edit: But if we do throw our hands up and give up on making limited-admin as secure as possible, let's admit that's what we've done and not inflict pointless UAC prompts on third-party software just for show.