Standard Account vs Admin Account

[Nighthawk15]

My question is not strictly about AV programs but this seems like the most relevant section....

In Windows Vista, are most of you on standard or Admin accounts? I think this is very important from a pseudo-sandboxing point of view (perhaps as important as any other measure such as AV,AS,AM,firewalls etc).

In XP, admin accounts were dangerous and using standard accounts was much safer (and very restrictive).

In Vista, with UAC OFF, it's a bit like XP in that the admin accounts have full privelage whereas the standard accounts are incapable of even the most routine tasks (with UAC OFF, you cannot even increase your privelage temporarily or run things as admin).

With UAC on, the standard users can run all tasks(installations/important changes) by being prompted to enter admin passwords. However, with UAC on, the same sort of protection is offered to admin accounts too; the notification window pops up.

So my question then is, for windows vista with UAC ON, is there any possible advantage to running a standard account instead of an admin one(like the XP days)? Does it offer any greater protection (however small or trivial) or is the admin account with UAC just as safe.

Note: If it helps, 99% of my infections are USB drive/Flash drive acquired and almost nothing infects me from the internet. [I'm assuming this is the case for most home computers?]

Thank you very much

[PoetWarrior]

I've been back and forth on this same question also. I'm running as protected admin now without having any malware trouble. Have had a few websites try to install something, but the UAC alerted me and I declined. I think the standard user does have the advantage of a partial virtualized registry. As I understand it this protects the Vista core from being corrupted. Very good question for Vista users.

If you're the only one using your computer you could use a standard account with an admin blank password. That would obviously cut down on typing.

[MrBrian]

From http://msinfluentials.com/blogs/jesp...really-is.aspx:

However, how do we mitigate the risk of privilege escalation between processes? It depends on our risk management philosophy. In the book, I laid out the increasing order of security of different ways to become an administrator:

Good: Run in admin-approval mode
Better: Run as standard user and elevate to separate admin account
Best: Run as standard user and switch user to a separate admin account instead of using UAC to elevate

Pick whichever one of these works best for you and provides you a level of protection you are comfortable with.

[PoetWarrior]

So if I run "best" security practices, then why use UAC? Shouldn't I simply turn UAC off?

Great article...thanks for the info. I just ordered his Vista security book.

[sukarof]

In Windows Vista, are most of you on standard or Admin accounts?

I´m on a standard account. I have UAC turned off and I use Surun and Software Restriction Policies.

[PoetWarrior]

I'm going to try using standard account with UAC turned off and see if I notice any performance change.

[Osaban]

I run on admin account and UAC on. I think one the great improvements of Vista over XP has been in the security department, but most people tend to to turn UAC off (!?) complaining about too many alerts. It doesn't bother me (I don't get so many alerts anyway), and apparently UAC is also very effective against rootkits (sorry I can't supply any link, they were testing rootkits on a Vista system, and surprisingly UAC stopped most of them).

[PoetWarrior]

Since the above mentioned article suggests best security practices is to use a Vista standard account and not elevate privileges from that same account, but go to the admin account to install software, then I'm going to try that with the caveat of also turning UAC off to notice any performance improvements.


Additional:

I know this is subjective, but so far I have "felt" a slight sluggishness go away since making the above change.

This particular setup may be what I've been looking for. Done a lot of experimenting with performance vs security setups.

[Rmus]

Originally Posted by Osaban

apparently UAC is also very effective against rootkits (sorry I can't supply any link, they were testing rootkits on a Vista system, and surprisingly UAC stopped most of them).

Here is one writeup. I noted this comment:

http://www.neowin.net/news/main/08/0...nails-rootkits

For Vista, only six rootkits could run on the OS, but the testers had to turn off UAC to get even this far. Vista's UAC itself spotted everything thrown in front of it.

In a period of where Vista has received criticism, Microsoft's programmers can at least point to evidence
that UAC is efficient at stopping infections from happening automatically.

Originally Posted by PoetWarrior

I'm running as protected admin now without having any malware trouble. Have had a few websites try to install something, but the UAC alerted me and I declined.

Unfortunately this prevention protection is not talked about much.

I investigated Vista's UAC protection in another thread, and asked a couple of people to test -- one provided the screenshot:

http://www.wilderssecurity.com/showp...&postcount=124

--

[PoetWarrior]

@Rmus:

Yep, it's been a confusing topic for me. Most of the time I've stayed with admin and UAC on. I never considered using the standard account with the UAC turned off. So I'm going to give that a go for awhile. Already liking Vista's response to turning it off.

In fact, I've downloaded antivir free to feel the effects on performance. I already have Window Defender turned on and system restore turned off.

[MrBrian]

Originally Posted by PoetWarrior

So if I run "best" security practices, then why use UAC? Shouldn't I simply turn UAC off?

Great article...thanks for the info. I just ordered his Vista security book.

You're welcome .

I've also read that turning off UAC also turns off the file and registry virtualization that allows some programs to work with a standard account without problems. Thus there might be good reason to keep UAC on even if you don't intend to elevate.

[MrBrian]

Turning off UAC also disables Internet Explorer protected mode.

[Osaban]

Originally Posted by Rmus

Here is one writeup. I noted this comment:

http://www.neowin.net/news/main/08/0...nails-rootkits
Unfortunately this prevention protection is not talked about much.

I investigated Vista's UAC protection in another thread, and asked a couple of people to test -- one provided the screenshot:

http://www.wilderssecurity.com/showp...&postcount=124

--

Quite remarkable, UAC behaves as a basic AntiExecutable. Could one rely on it completely as an antiexecutable? It'd be nice if somebody skilled enough ran some thorough tests of UAC.

[Rmus]

I made several drive-by download tests that various people used. Unfortunately, they require IE6 and so wouldn't work on Vista.

But the use of AutoRun.inf to trigger a download -- both on CD and USB stick -- was successfully blocked by Vista's UAC.

One of the tests uses a spoofed executable -- which would be interesting to see how Vista responds.

Also MrBrian's script tests he showed in another thread would be nice to try.

--

[PoetWarrior]

Well after trying out my aforementioned setup (standard acc. with no UAC) I returned to protected admin (UAC turned back on). I did start having glitches with a game and NVidia card.


So I'm back to good security practice instead of best. I'll have to decide whether to go for better or stick with good security practice.

[Nighthawk15]

I live in a residential college and all the "shady" hacker/IT types keep Vista in admin mode with UAC off. Mostly because they want full control and don't care much about security from a LUA perspective. However they recommend keeping UAC on for regular users. One of them said what applied to XP doesn't apply to vista and for the vast majority of cases;

Admin with UAC on = Standard User with UAC on, so basically UAC removes the distinction *almost*.

With UAC off, the Admin and standard accounts revert to XP style. However, one of them said that

Admin with UAC on might be safer than standard user with UAC off. He himself runs linux but said on XP, even standard users had write access to 5-6 registry locations, so in vista if those priveleges remain, then standard user with UAC off would not be notified if those locations are modified whereas an admin (or standard user) with UAC on would be. Something to the same effect has been said in this thread:

http://www.wilderssecurity.com/showthread.php?t=196737
[post no.25 by tlu]

Combine this with the fact that if you use standard user with UAC on, you will have to keep entering your admin password and I'm beginning to think the safest way with Vista is actually Admin with UAC.

To sum up, in my current understanding

Admin with UAC ON >= Standard user with UAC ON > Standard user with UAC OFF> Admin with UAC OFF

where > means safer than.

[sukarof]

This is confusing indeed. I try to read different blogs but I dont get any wiser...

This is how understand it:
In Vista the admin account is actually a limited user account until you give the concent to run the task via the UAC prompt. When you hit that UAC prompt your account is elevated to admin rights for that specific task.

In LUA you run admin tasks as a totally different user and have to log into that user account to do the same thing as you do in Admin+UAC. Basicly the same as in old XP.
Or am I missing something here?
Please educate me someone coz I have been running Vista for a long time but I still havent fully understood what a LUA does different (safer or less safe) than UAC. (I am the only user of this computer so I dont mean the password in LUA now)
In what way does Vista behave differently behind the scene in LUA (vs admin+UAC)?

[MrBrian]

Originally Posted by sukarof

This is confusing indeed. I try to read different blogs but I dont get any wiser...

From Understanding and Configuring User Account Control in Windows Vista:

When an administrator logs on, the user is granted two access tokens: a full administrator access token and a "filtered" standard user access token. By default, when a member of the local Administrators group logs on, the administrative Windows privileges are disabled and elevated user rights are removed, resulting in the standard user access token. The standard user access token is then used to launch the desktop (Explorer.exe). Explorer.exe is the parent process from which all other user-initiated processes inherit their access token. As a result, all applications run as a standard user by default unless a user provides consent or credentials to approve an application to use a full administrative access token. Contrasting with this process, when a standard user logs on, only a standard user access token is created. This standard user access token is then used to launch the desktop.

A user that is a member of the Administrators group can now log in, browse the Web, and read e-mail while using a standard user access token. When the administrator needs to perform a task that requires the administrator access token, Windows Vista automatically prompts the user for approval. This prompt is called an elevation prompt, and its behavior can be configured in the Security Policy Editor (secpol.msc) snap-in and with Group Policy. For information about how to adjust UAC Group Policy settings, see the "Configuring UAC Settings" section within this document.

I'm not sure what the reasoning behind the difference between the 'good' and 'better' recommendations from post #3 is, assuming that a user already knows the admin password. THe only difference I see so far is that, by default, the former requires just a click for elevation while the latter requires a password for elevation, and thus perhaps the first could be done more easily without thought.

[PoetWarrior]

I guess I need to understand what is virtualized in the standard account and why. Does the partial virtualized registry and files create and even tighter container to protect Vista's core even more than running as protected Admin (UAC on)? Let me try and get clearer for myself here. Is there an additional security purpose for the virtualized registry, etc. in the standard account or is it a matter of simply assisting programs to run correctly? If there is a security purpose, then that would help me determine if I should run protected Admin or standard user. If the virtualized registry is simply for helping programs run correctly in the standard user account, then I'll stay with protected admin.

[Dogbiscuit]

Microsoft: UAC not a security feature

In a Microsoft TechNet blog post, Russinovich explained that Vista features such as UAC or Protected Mode Internet Explorer that are dependent on limited user privileges -- which Microsoft calls Integrity Levels (IL) -- are designed to allow some IL breaches.

"If you aren't guaranteed that your elevated processes aren't susceptible to compromise by those running at a lower IL, why did Windows Vista go to the trouble of introducing elevations and ILs? To get us to a world where everyone runs as standard user by default and all software is written with that assumption," he wrote.

[PoetWarrior]

@Dogbiscuit

If you get a chance, check out the article mentioned in post #3 to read the debate between Microsoft's denial and others who disagree with MS and consider UAC a security feature of Vista. It's a great read.

[Dogbiscuit]

Yes, thanks. It seems to me that regardless of nominclature, and regardless of the added protection, UAC wasn't designed to provide 'airtight' security (unlike a HIPS w/execution control), unless something has changed.

And FWIW, I personally know for a fact that it's not that difficult to breach limted user accounts to gain administrator privileges. Which is why using a standard account with SRP (and a few registry modifications) is safer still than simply using standard accounts by themselves.

[Rmus]

Keep in mind that as Operating Systems evolve, the same two methods of delivering malware remain:

1) Install by remote code execution --from the internet, removable media (USB), or unsuspecting "click" of spoofed malware in email

2) Consent of the user -- program installed turns out to be infected.

Until WinXP, the first method had to be dealt with by another application. Software Restriction Policies provide protection against this.

WinVista and UAC seem to offer the same protection.

But with WinVista and UAC, more emphasis has been given to the second method: how does UAC deal with/contain malware that executes? Lots of talk about "sandboxing" and "Integrity Levels" and "Elevated Previleges." Such as:

PsExec, User Account Control and Security Boundaries
http://blogs.technet.com/markrussino...12/638372.aspx

Protected Mode IE and PsExec's -l option simply take advantage of ILs to create a sandbox around malware that gets past other security defenses.

But some have questioned its effectiveness in this area:

The official blog of the invisiblethings.org
http://theinvisiblethings.blogspot.c...every-day.html

imagine a reliable exploit (i.e. not crashing a target too often) which, after exploiting e.g. IE Protected Mode process, steals all the user's DOC and XLS files, sends them back somewhere and afterwards disappears in an elegant fashion...

When attacker successfully exploit bug, then all the security scheme implemented by the OS is just worth nothing.

Yet others are adament UAC should act in the manner of a HIPS-type product. Here, for instance, a comment following this blog:

http://theinvisiblethings.blogspot.c...-big-joke.html

What the UAC should do is tell you things like a program is setting itself to start automatically at startup, but it doesn't do that, once you say it is alright for a setup program to run the setup can do whatever it likes without any UAC prompt.

For an example I recently installed Nero 8 on Vista with UAC on. It prompted for the setup to run, during setup Nero set 3 program to auto start with Windows, without the setup telling me or UAC. After unistalling Nero the 3 programs set to suto start were still there, I had to remove them manually through registry.

Stuff like that is what causes winrott and malware. All the UAC does is ask when you double click on something are you sure you wanted to, not much else.

Another comment puts into perspective the two methods of attack:

You are all missing the point of UAC. It is not going to tell you if the software that is trying to install is safe and free of trojans. It's going to stop the software from installing until the user allows the install. If the user is truly concerned about security that user will only install software that they trust.

Most normal users actually know enough to not install software from an untrusted source because they have been hearing it said for several years now. The problem is that most normal users don't know they could be installing software by oening an email attachment that looks like an image file. UAC gives a warning that can prevent that from happening.

And so, we are left pretty much in the same state of affairs.

Attack Method 1 is easy to deal with by various solutions, from the OS (SRP, UAC) to 3rd party applications

Attack Method 2 boils down to, "How do I know the program is safe?" No Operating System Configurations, this account or that account, no other technological device can make that decision or be 100% sure.

Only the user can answer and determine and make that decision to her/his satisfaction and comfort, and level of trust.

--

[MrBrian]

Originally Posted by PoetWarrior

I guess I need to understand what is virtualized in the standard account and why. Does the partial virtualized registry and files create and even tighter container to protect Vista's core even more than running as protected Admin (UAC on)? Let me try and get clearer for myself here. Is there an additional security purpose for the virtualized registry, etc. in the standard account or is it a matter of simply assisting programs to run correctly? If there is a security purpose, then that would help me determine if I should run protected Admin or standard user. If the virtualized registry is simply for helping programs run correctly in the standard user account, then I'll stay with protected admin.

Here is a nice article from Microsoft that answers your question. The virtualization is there so that programs that write to Program Files and Windows and HKLM in the registry are redirected so that they'll work in a standard user account. If you turn UAC off, I believe you lose this virtualization, a loss which malware could also take advantage of. But turning off UAC also disables Vista's integrity levels, I believe, which has security implications such as neutering protected mode for Internet Explorer. Here is a non-Microsoft post that makes these same claims, but I'll see if I can find a more official source. From the last source:

For starters think before you disable or set UAC to Silent Mode, can you live with it? The prompts do bring in an added level of security. If you cannot live with them:

The answer isn't to entirely disable UAC but to set UAC to automatically elevate the prompts for you (i.e - Click on OK automatically), also known as "Silent Mode". This can be done using Group Policy Editor on Vista Ultimate, Vista Business or Vista Enterprise but for Vista Home Premium and Vista Home Basic you need:

TweakUAC

[MrBrian]

Originally Posted by MrBrian

I'm not sure what the reasoning behind the difference between the 'good' and 'better' recommendations from post #3 is, assuming that a user already knows the admin password. THe only difference I see so far is that, by default, the former requires just a click for elevation while the latter requires a password for elevation, and thus perhaps the first could be done more easily without thought.

Bingo! I just found the answer to the difference between the 'good' and 'better' recommendations (which is our topic here), in the Microsoft article mentioned in my last post:

Elevated AAM [Admin Approval Mode] processes are especially susceptible to compromise because they run in the same user account as the AAM user’s standard-rights processes and share the user’s profile. Many applications read settings and load extensions registered in a user’s profile, offering opportunities for malware to elevate. For example, the common control dialogs load Shell extensions configured in a user’s registry key (under HKEY_CURRENT_USER), so malware can add itself as an extension to load into any elevated process that uses those dialogs.

Even processes elevated from standard user accounts can conceivably be compromised because of shared state. All the processes running in a logon session share the internal namespace where Windows stores objects such as events, mutexes, semaphores, and shared memory. If malware knows that an elevated process will try to open and read a specific shared memory object when the process starts, it could create the object with contents that trigger a buffer overflow to inject code into the elevated process. That type of attack is relatively sophisticated, but its possibility prevents OTS elevations from being a security boundary.

The bottom line is that elevations were introduced as a convenience that encourages users who want to access administrative rights to run with standard user rights by default. Users wanting the guarantees of a security boundary can trade off convenience by using a standard user account for daily tasks and Fast User Switching (FUS) to a dedicated administrator account to perform administrative operations. On the other hand, users who want to forgo security in favor of convenience can disable UAC on a system in the User Accounts dialog in the Control Panel, but should be aware that this also disables Protected Mode for Internet Explorer.

Thus, there is good reason to use a standard account instead of an administrator account in Vista.

By the way, it's also recommended in the same article that elevation from a standard account should be configured to require CTRL+ALT+DEL:

Even though elevation dialogs appear on a separate secure desktop, users have no way by default of verifying that they are viewing a legitimate dialog and not one presented by malware. That isn’t an issue for AAM because malware can’t gain administrative rights with a faked Consent dialog, but malware could wait for a standard user’s OTS elevation, intercept it, and use a Trojan horse dialog to capture administrator credentials. With those credentials they can gain access to the administrator’s account and infect it.

For this reason, OTS elevations are strongly discouraged in corporate environments. To disable OTS elevations (and reduce help desk calls), run the Local Security Policy Editor (Secpol.msc) and configure "User Account Control: Behavior of the elevation prompt for standard users" to "Automatically deny elevation requests."

Home users who are security-conscious should configure the OTS elevations to require a Secure Attention Sequence (SAS) that malware cannot intercept or simulate. Configure SAS by running the Group Policy Editor (Gpedit.msc), navigating to Computer Configuration | Administrative Templates | Windows Components | Credential User Interface, and enabling "Require trusted path for credential entry." After doing so you will be required to enter Ctrl+Alt+Delete to access the elevation dialog.