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

[MrBrian]

From http://msinfluentials.com/blogs/jesper/archive/2007/03/01/confusion-about-vista-features-what-uac-really-is.aspx:

{QUOTE->
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. <-QUOTE}

[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]

{QUOTE-> In Windows Vista, are most of you on standard or Admin accounts? <-QUOTE}

I´m on a standard account. I have UAC turned off and I use Surun (http://www.wilderssecurity.com/showthread.php?t=196737&highlight=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]

{QUOTE-> 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). <-QUOTE}Here is one writeup. I noted this comment:

http://www.neowin.net/news/main/08/05/25/tests-find-vistas-uac-nails-rootkits
{QUOTE-> 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. <-QUOTE}{QUOTE-> 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. <-QUOTE}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/showpost.php?p=1277832&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. :blink:

[MrBrian]

{QUOTE-> 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. <-QUOTE}

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]

{QUOTE-> Here is one writeup. I noted this comment:

http://www.neowin.net/news/main/08/05/25/tests-find-vistas-uac-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/showpost.php?p=1277832&postcount=124

-- <-QUOTE}

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]

{QUOTE-> This is confusing indeed. I try to read different blogs but I dont get any wiser...
<-QUOTE}

From Understanding and Configuring User Account Control in Windows Vista (http://technet2.microsoft.com/WindowsVista/en/library/00d04415-2b2f-422c-b70e-b18ff918c2811033.mspx?mfr=true):

{QUOTE-> 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. <-QUOTE}

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 (http://www.networkworld.com/news/2007/021407-microsoft-uac-not-a-security.html)
{QUOTE-> In a Microsoft TechNet blog post (http://blogs.technet.com/markrussinovich/archive/2007/02/12/638372.aspx), 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. <-QUOTE}{QUOTE->
"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. <-QUOTE}

[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/markrussinovich/archive/2007/02/12/638372.aspx

{QUOTE-> 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. <-QUOTE}But some have questioned its effectiveness in this area:

The official blog of the invisiblethings.org
http://theinvisiblethings.blogspot.com/2007/02/running-vista-every-day.html

{QUOTE-> 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. <-QUOTE}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.com/2007/02/vista-security-model-big-joke.html
{QUOTE-> 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. <-QUOTE}Another comment puts into perspective the two methods of attack:

{QUOTE-> 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. <-QUOTE}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]

{QUOTE-> 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. :-\ <-QUOTE}

Here (http://technet.microsoft.com/en-us/magazine/cc138019.aspx) 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 (http://www.bulletsnbabesdvd.com/forums/viewtopic.php?t=4338) 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:

{QUOTE-> 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 <-QUOTE}

[MrBrian]

{QUOTE->
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. <-QUOTE}

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:

{QUOTE->
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.
<-QUOTE}

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:

{QUOTE-> 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. <-QUOTE}

[PoetWarrior]

To All,

Thanks for a fascinating discussion on Vista's UAC and standard accounts. I'm going to try and digest the new info by MrBrian and Rmus. Lot's of great stuff here. Thanks guys. :thumb:

[MrBrian]

{QUOTE-> To All,

Thanks for a fascinating discussion on Vista's UAC and standard accounts. I'm going to try and digest the new info by MrBrian and Rmus. Lot's of great stuff here. Thanks guys. :thumb: <-QUOTE}

You're welcome and thanks also :).

The info presented here also helped clarify the situation for me. From my last post, it seems there is good reason to use a standard account in Vista instead of an administrator account.

[Rmus]

{QUOTE-> Here (http://technet.microsoft.com/en-us/magazine/cc138019.aspx) is a nice article from Microsoft ... Here (http://www.bulletsnbabesdvd.com/forums/viewtopic.php?t=4338) is a non-Microsoft post <-QUOTE}Thanks for those links. I'm building a "reading file" and it's quite overwhelming at first to sort out what VISTA and UAC really do!

If knowledgeable people here are searching to understand all of this, I don't know how the average Mr. and Mrs. Smith, upgrading to VISTA, can know what to do, how to configure, etc.

--

[MrBrian]

{QUOTE-> Thanks for those links. I'm building a "reading file" and it's quite overwhelming at first to sort out what VISTA and UAC really do!
<-QUOTE}

You're welcome :). The Microsoft source I cited is as definitive of a source as you will find, and it helped answer my own questions too.

[MrBrian]

{QUOTE->
If knowledgeable people here are searching to understand all of this, I don't know how the average Mr. and Mrs. Smith, upgrading to VISTA, can know what to do, how to configure, etc.
<-QUOTE}

I'd suspect that in a home environment most will use the default settings.

[MrBrian]

Whether to virtualize file and registry writes is a setting you can control. See here (http://itsvista.com/2006/12/learn-how-to-disable-vistas-uac-and-why-you-shouldnt/) for this and the other UAC settings you can control.

[Rmus]

Suppose someone wants to install programABC.exe from a shareware site.

The user scans the download and it comes up clean.

But, it is really infected.

The user gives permission to install.

As I understand what I've read, once you give permission to install, then VISTA has no way of telling whether or not the file is not clean.

--

[MrBrian]

{QUOTE-> Suppose someone wants to install programABC.exe from a shareware site.

The user scans the download and it comes up clean.

But, it is really infected.

The user gives permission to install.

As I understand what I've read, once you give permission to install, then VISTA has no way of telling whether or not the file is not clean.
<-QUOTE}

From my understanding, yes that's correct. I'd disagree with some others that this is not an issue. For example, 3 of the top 10 results in a Google search for 'screensaver' are questionable links, according to scandoo.

[MrBrian]

{QUOTE-> 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 (http://www.bulletsnbabesdvd.com/forums/viewtopic.php?t=4338) is a non-Microsoft post that makes these same claims, but I'll see if I can find a more official source. <-QUOTE}

I found a Microsoft article (http://technet2.microsoft.com/WindowsVista/en/library/00d04415-2b2f-422c-b70e-b18ff918c2811033.mspx?mfr=true) that verifies this:

{QUOTE-> Disabling the User Account Control: 'Run administrators in Admin Approval Mode' setting turns UAC “off.” Files and folders are no longer virtualized to per-user locations for non-UAC compliant applications and all local administrators are automatically logged in with a full administrative access token. Disabling this setting essentially causes Windows Vista to revert to the Windows XP user model. <-QUOTE}

Post #25 contains an official source for the Internet Explorer protected mode statement.

[Rmus]

{QUOTE-> As I understand what I've read, once you give permission to install, then VISTA has no way of telling whether or not the file is not clean. <-QUOTE}
{QUOTE-> From my understanding, yes that's correct. <-QUOTE}In that case, what does it matter in which account a user runs?

==> In either, UAC will alert to any attempt at a drive-by or otherwise method to sneak in malware.

==> In either, the user has to make the ultimate decision to install a program.

In these two scenarios, how is VISTA any improvement in security over someone with Win98 and ProcessGuard?

(This is not directed just to you, but to all others struggling with how to configure VISTA)

--

[sukarof]

{QUOTE->

As I understand what I've read, once you give permission to install, then VISTA has no way of telling whether or not the file is not clean.

-- <-QUOTE}

Yes, UAC is not a HIPS or a malware detector. AFAIK that is a problem in every OS I guess (but windows is more at risk since it is the most popular target for the malware creators) If a malware gets past your security software in [input optional OS here] and you give it "root" access, it can do whatever it wants. Unless you have a HIPS that gives a prompt for every move the installer does and you know exactly what that specific installer is allowed to do, then you´re pretty safe...

One security degrading factor in UAC is, as the experts point out, that every software installation requires an elevation to admin. It is good that you get alerted when something wants to install, but it is no good that even software installs that doesnt need the admin rights (ie write to sensitive areas, like windows- or system32 folder for example) also gets full access to the senisitive areas. But I guess it is difficult for UAC to determine what software wont write to sensitive areas.

[MrBrian]

{QUOTE-> In that case, what does it matter in which account a user runs?

==> In either, UAC will alert to any attempt at a drive-by or otherwise method to sneak in malware.

==> In either, the user has to make the ultimate decision to install a program.

In these two scenarios, how is VISTA any improvement in security over someone with Win98 and ProcessGuard?
<-QUOTE}

Consider a buffer overflow exploit targeting a media player, for example. If this happens in an administrator account, the malware would have a greater surface area to attack (without triggering an elevation prompt), as compared to the same thing happening in a standard account. Also, if you get an elevation prompt during such an exploit, it would hopefully trigger the user's suspicion. This example can be generalized to any malicious code that's able to run, whether it's via a buffer overflow exploit or via other means.

[PoetWarrior]

{QUOTE-> In that case, what does it matter in which account a user runs?

==> In either, UAC will alert to any attempt at a drive-by or otherwise method to sneak in malware.

==> In either, the user has to make the ultimate decision to install a program.

In these two scenarios, how is VISTA any improvement in security over someone with Win98 and ProcessGuard?

(This is not directed just to you, but to all others struggling with how to configure VISTA)

-- <-QUOTE}


That's why I wanted to know how virtualization/security worked in Vista with a standard account. I'm still working through reading all the new info, but I was under the hazy impression that a standard user account created a security barrier not present with the administrator (UAC on), and this difference kept the entire system from being corrupted. Kind of minimized the damage. Pardon me for being slow on this subject, but there's much to digest which I'm slowly doing. :lurking:

[MrBrian]

{QUOTE->
One security degrading factor in UAC is, as the experts point out, that every software installation requires an elevation to admin. It is good that you get alerted when something wants to install, but it is no good that even software installs that doesnt need the admin rights (ie write to sensitive areas, like windows- or system32 folder for example) also gets full access to the senisitive areas. <-QUOTE}

Those who use HIPS might find them handy during installations in Vista because of this issue. I have an installer policy in my HIPS that allows common actions such as writing to Program Files but prompts on other actions such as writing to Windows directory, autostart locations, etc.

[PoetWarrior]

{QUOTE-> Consider a buffer overflow exploit targeting a media player, for example. If this happens in an administrator account, the malware would have a greater surface area to attack (without triggering an elevation prompt), as compared to the same thing happening in a standard account. <-QUOTE}


OK, that's making sense to me and well said. I think I see the sun breaking from behind the clouds. :thumb:

[MrBrian]

{QUOTE-> I'm still working through reading all the new info, but I was under the hazy impression that a standard user account created a security barrier not present with the administrator (UAC on), and this difference kept the entire system from being corrupted. <-QUOTE}

From post #25, you indeed are better off using a standard user account than an administrative account, assuming UAC is on. Of course, if you elevate malware itself, then in either type of account you could be totally compromised.

[Rmus]

Regarding installing of programs that might be infected:

{QUOTE-> I'd disagree with some others that this is not an issue. 3 of the top 10 results in a Google search for 'screensaver' are questionable links, according to scandoo. <-QUOTE}
{QUOTE-> Consider a buffer overflow exploit targeting a media player, for example. <-QUOTE}Would you put one's choice of of a media file to play in the same category as one's choice of a screen saver?

Also, do you have any links to test a media file exploit? I've even tried some PoC examples but none have run on my system.

The only write up I've seen which had a link (dead when tried) showed that the payload was an attempt to install a trojan dropper - would be blocked by my example above with PG and Win98.

--

[MrBrian]

I found a nice 57 slide PowerPoint document by the same author as the Microsoft article from post #25. It covers much the same territory, but also has some additional information. The document is WLC404 User Account Control Internals and Impact on Future Malware (https://espace.cern.ch/NICE-Techmeetings/Document%20Library/1/2006/2006-12-04%20WCL404_Windows%20Vista%20User%20Account%20Control%20Internals.ppt).

[MrBrian]

{QUOTE->
Would you put one's choice of of a media file to play in the same category as one's choice of a screen saver?

Also, do you have any links to test a media file exploit? I've even tried some PoC examples but none have run on my system.
<-QUOTE}

IMHO, no, because most users wouldn't know that playing a media file could cause malicious executable code to run.

I don't have any links offhand, sorry. That was just a particular example. I meant the most general case to be what malware could do in an account without needing elevation. You could substitute any program that you run without elevation.

[sukarof]

{QUOTE-> Those who use HIPS might find them handy during installations in Vista because of this issue. I have an installer policy in my HIPS that allows common actions such as writing to Program Files but prompts on other actions such as writing to Windows directory, autostart locations, etc. <-QUOTE}
Yeah, HIPS are great in that sense. But they require that the user knows which of those prompts are malware related and which isnt. Even though a good HIPS gives tips on why it prompts it still prompts for mostly legit operations during software installation.
I used HIPS for several years but I wasnt skilled enough to differentiate them so for me they where a waste of time (well not entirely, they where good education on what happens during software installations).
But nowadays many HIPS has whitelisted many software and that is a good thing that makes them less intrusive.

[PoetWarrior]

The following comes from the WLC404 User Account Control Internals and Impact on Future Malware document.

"Windows will evolve further to promote standard user:

Per-user installations

Secure elevations"


So I guess in some ways I thought Vista security a little more evolved than it actually is especially on these two points. I was hoping the standard account isolated "bad" installations. Once past the UAC, the user is successfully infiltrated. :o (assuming no AV, AS, etc.)

[MrBrian]

{QUOTE->
So I guess in some ways I thought Vista security a little more evolved than it actually is especially on these two points. I was hoping the standard account isolated "bad" installations. Once past the UAC, the user is successfully infiltrated. :o <-QUOTE}

Also, even without needing administrative priviliges, malicious code run in even a standard account can start automatically in the account, tamper with or steal your data, steal your keystrokes, hide itself from the user, etc.

[Rmus]

{QUOTE-> I don't have any links offhand, sorry. That was just a particular example. I meant the most general case to be what malware could do in an account without needing elevation. <-QUOTE}OK. That sounds like a good reason not to run in an Administrator Account.

My reason for examples is I like to know what specific attacks are doing so as to know what to prepare for and how to protect.

Security advisories are usually pretty general about vulnerability impacts, since they have to cover all bases. An example:

http://www.securityfocus.com/archive/1/493849
{QUOTE-> Successful exploitation may allow execution of arbitrary code. <-QUOTE}All payloads of current buffer overflow attacks I've seen described install trojans.

For someone concerned about other "artibrary code" it would be nice to find current attacks so as to test against VISTA. Unfortunately, there aren't any. In that case, is a a real threat?

For someone who is concerned that it is a real threat, it might turn out that a product that specifically monitors for buffer overflow would be better protection.

--

[PoetWarrior]

The good thing is that I haven't had any malware or virus in a long time, but this thread makes me think I need to rethink my security setup with Vista now. I really don't like loading down the OS with tons of security software. I'm using Windows Defender, KeyScrambler plus all the software necessary for a complete recovery and have gone back to a separate standard user account now. I really don't want to run anymore external stuff. :gack:

[MrBrian]

{QUOTE->
All payloads of current buffer overflow attacks I've seen described install trojans.
<-QUOTE}

Even in a standard account, you could justify the use of Anti-Executable, Software Restriction Policies, realtime antivirus, HIPS, outbound firewalls, etc.

[Rmus]

{QUOTE-> Even in a standard account, you could justify the use of Anti-Executable, Software Restriction Policies, realtime antivirus, etc. <-QUOTE}True, but I'm hoping to learn the limits of UAC by itself!

Not having Vista to test myself, I've had to rely on others, who are not really set up to test malware. But they've shown how UAC blocks AutoRun.inf from launching a payload, which is an indication of it's protection against the remote code execution type of exploit.

If this is so, then I don't think one needs any other type of security, since the other types of infections depend on the user consenting to install something, a decision that no security product can make!

As far as scanning a program before installing, all that proves is that on this day at this time, the scanner (or 32 at Virus Total) says it is clean. The user trusts the scanning results.

Another user trusts her/his judgment for choosing legitimate sofware from known sites.

Since neither is 100% sure, I don't see any difference in which method one chooses. It all depends on which provides the user with the most peace of mind.

The latter method means one less program to fiddle with.

If there is a concern that a mistake might be made in this situation, then a good imaging or restore solution should help with one's peace of mind!

--

[MrBrian]

{QUOTE->
If this is so, then I don't think one needs any other type of security, since the other types of infections depend on the user consenting to install something, a decision that no security product can make!
<-QUOTE}

Consider this example. You're using Vista with a standard account. You play an infected movie file with a vulnerable media player. The buffer overflow exploit code downloads and runs a program which steals all of your documents. No elevation was needed in this case. This type of damage is not recoverable with an image restore. Some of these other technologies could have prevented this though.

[Rmus]

{QUOTE-> The buffer overflow exploit code downloads and runs a program which steals all of your documents. <-QUOTE}This is what I haven't been able to test: would UAC alert to the exploit code attempting to download a program?

If no, then other security is needed.

--

[MrBrian]

{QUOTE->
Not having Vista to test myself, I've had to rely on others, who are not really set up to test malware. But they've shown how UAC blocks AutoRun.inf from launching a payload, which is an indication of it's protection against the remote code execution type of exploit.
<-QUOTE}

I've seen your post in another thread about the USB autorun. Thank you for posting it. The UAC alert does make it appear as if the execution itself was blocked, but I think that is not really what happened. If you look at Fig. 11 of http://technet.microsoft.com/en-us/magazine/cc138019.aspx, you'll see that that's the exact same prompt you receive when an unknown program seeks elevation. In other words, it was the elevation that caused the UAC alert. If the USB autorun hadn't required elevation, then you would have received no prompt at all. I believe it's the poorly worded alert that caused the confusion. In the example you posted, the executable contained the word 'setup'. That alone would have triggered an elevation request.

[MrBrian]

{QUOTE-> This is what I haven't been able to test: would UAC alert to the exploit code attempting to download a program?

If no, then other security is needed.
<-QUOTE}

From what I've read, there would be no alert, unless elevation is involved.

Vista is not immune to malware. According to this study (http://www.computerworld.com.au/index.php/id;128348660;fp;16;fpid;1) (here (http://www.pctools.com/news/view/id/206/) too) from PC Tools' ThreatFire statistics, 27% of Vista machines monitored by ThreatFire had at least one piece of malware detected during the six month period of the study. That's not necessarily an indictment of Vista, because some users turn off UAC, make poor decisions on UAC prompts, etc.

I view UAC and running as a standard user as protections against system compromise. Even without system compromise though, malware can do many undesirable things. According to Windows internals guru Mark Russinovich, "the malware author will say, 'I can live in a Vista world without needing to take over the entire box,'" he said. "They will end up thriving in the standard user environment, setting up botnets, grabbing your keystrokes." (source (http://arstechnica.com/news.ars/post/20070430-microsofts-guru-malware-and-viruses-will-evolve-on-vista.html))

Microsoft itself recommends (http://blogs.msdn.com/windowsvistasecurity/archive/2008/05/09/windows-vista-windows-2000-and-malware.aspx) the following:

{QUOTE-> Does this mean that anti-malware software isn’t necessary? Absolutely not. No software is perfect. While we have many defense-in-depth improvements in Windows Vista, it’s critical for consumers to follow the Protect Your PC guidance of keeping the firewall turned on, keeping the operating system up to date, and having up to date anti-virus and anti-spyware software. <-QUOTE}

[Rmus]

{QUOTE-> From what I've read, there would be no alert, unless elevation is involved. <-QUOTE}I'll have to accept that for now, not having any way of testing myself.

Thanks for your research into all of this!

--

[MrBrian]

{QUOTE-> I'll have to accept that for now, not having any way of testing myself.
<-QUOTE}

I didn't test it either, but I've seen nothing to indicate otherwise.

[Rmus]

Well, nothing is confirmed until testing.

In another thread, two people showed that UAC alerts to an installation CD attempting to install, and to a USB drive attempting to run an executable.

I concluded that this suggests that UAC might protect against any attempt to install a program by remote code execution.

Statements in your links indicate this might not be so. That would be a serious compromise, in my opinion.

Until I find someone who can test an exploit, I reserve making any judgment.


EDIT: sorry - I didn't see your other post until now:

{QUOTE-> In other words, it was the elevation that caused the UAC alert. If the USB autorun hadn't required elevation, then you would have received no prompt at all. I believe it's the poorly worded alert that caused the confusion. In the example you posted, the executable contained the word 'setup'. That alone would have triggered an elevation request. <-QUOTE}Yes, I remember the comment in one of the links about 'setup.'

If this is the criteria which UAC uses to flag executables, then it is really weak indeed as far as secure protection against any remote code execution. In other words, it is not anything at all like SRP.

Regarding the other thread - the original remote code execution exploit I used (MS06-014) would not run on VISTA, so I resorted to asking them to test with CD and USB autorun.inf.

About the poorly worded Alert - I mentioned that to the two people and asked what the "Details" showed - nothing of any help.

Your thought about using additional protection with VISTA seems to be wise indeed.

--

[MrBrian]

{QUOTE-> Well, nothing is confirmed until testing.

In another thread, two people showed that UAC alerts to an installation CD attempting to install, and to a USB drive attempting to run an executable.

I concluded that this suggests that UAC might protect against any attempt to install a program by remote code execution.

Statements in your links indicate this might not be so. That would be a serious compromise, in my opinion.

Until I find someone who can test an exploit, I reserve making any judgment.
<-QUOTE}

I think in those cases you mention, because the word 'setup' was used in the program name, UAC figured elevation would be needed and perhaps the exe itself never ran before the UAC prompt was shown. But what if the word 'setup' was not in the program name....

[Rmus]

Yes - see my Edit in previous post.

--

[MrBrian]

{QUOTE-> In other words, it is not anything at all like SRP.
<-QUOTE}

That's correct, from what I've read. Vista still has SRP, and Microsoft has recommended its use in corporate environments for high security configurations. I believe that not all versions of Vista have SRP, by the way.

[Rmus]

Too bad:

http://www.mechbgon.com/srp/
{QUOTE-> you can't use Software Restriction Policy if you have Windows XP Home, Windows Vista Home Basic, or Windows Vista Home Premium, but Limited or Standard accounts are still strongly suggested. Try them out; you can always go back if they don't work well for your needs. <-QUOTE}

[MrBrian]

{QUOTE-> Too bad:

http://www.mechbgon.com/srp/ <-QUOTE}

Perhaps if you had a third-party program (such as SetSAFER in XP) that made the registry changes that the SRP user interface would have made, these editions would still enforce it. Something to look into.

[PoetWarrior]

{QUOTE-> I think in those cases you mention, because the word 'setup' was used in the program name, UAC figured elevation would be needed and perhaps the exe itself never ran before the UAC prompt was shown. But what if the word 'setup' was not in the program name.... <-QUOTE}


The UAC is not that lean, relying only on key words to determine elevation. It is a part of the process, but more is involved. In one of the articles read yesterday the UAC also has access to a heuristic to determine elevation.

[MrBrian]

{QUOTE-> The UAC is not that lean, relying only on key words to determine elevation. It is a part of the process, but more is involved. In one of the articles read yesterday the UAC also has access to a heuristic to determine elevation. <-QUOTE}

Yes you're right. I had meant to emphasize that if the magic words were not present, then code you didn't intend to run would still run. There is a list of UAC prompt triggers at http://en.wikipedia.org/wiki/User_Account_Control.

[PoetWarrior]

I've thought about this subject (standard vs protected admin account) today and have decided that my experience with Vista has to come into play with the info I've read. As I said in a previous post I've had no malware since using Vista (1.5 yrs) as protected admin, so Vista and I are doing something right.

I usually install a different virus package once a week and run a scan and so far nothing is found. Then I use FD-ISR to remove it and continue as before. If I were to find something I would not try to repair, rather I would use FD-ISR or Paragon to go back to a safe OS state.

Now I may have to consider new protection in the future when malware begins to systematically defeat the UAC, but right now I'm sticking with my current setup. The key here is flexibility on the battlefield. I'll adjust my approach when I feel the danger is coming too close to me. This has been a very interesting thread.

[MrBrian]

From UAC: Desert Topping, or Floor Wax? (http://blogs.msdn.com/crispincowan/archive/2008/04/28/uac-desert-topping-or-floor-wax.aspx):

{QUOTE->
But how much of a security feature is [UAC]? Does UAC provide a security boundary? That depends on which kind of user you are using, and how you use it.

Standard User Without OTS: this is a security boundary. There should not be any way for a non-privileged process to elevate to a privileged process, and if someone finds one, then Microsoft should issue a patch. Caveat: this is excluding mis-configurations such as 3rd party software running with privilege or weak security settings.

Standard User With OTS: this is questionable. There should not be any way to elevate, but in practice the OTS elevation presents potential area of attack. The attacker could inject malicious code into the user’s context, and it may trigger once the OTS elevation completes and the Administrator token is available.

Administrator in AAM: this is definitely not a security boundary. With the Administrator token available in the user’s space, it is too easy for malware to attack something in this very broad attack surface and gain elevation without the user’s approval. Microsoft could not patch this barrier without substantially breaking application compatibility.

Administrator in Silent Mode: Not even close to a security boundary. In silent mode, any malware in the user’s processes, such as an infection in the mail client, or in the web browser running at medium integrity, can ask for and get automatic elevation to Administrator.
<-QUOTE}

[tlu]

{QUOTE-> From UAC: Desert Topping, or Floor Wax? (http://blogs.msdn.com/crispincowan/archive/2008/04/28/uac-desert-topping-or-floor-wax.aspx):

Quote:
...

Standard User With OTS: this is questionable. There should not be any way to elevate, but in practice the OTS elevation presents potential area of attack. The attacker could inject malicious code into the user’s context, and it may trigger once the OTS elevation completes and the Administrator token is available.

Administrator in AAM: this is definitely not a security boundary. With the Administrator token available in the user’s space, it is too easy for malware to attack something in this very broad attack surface and gain elevation without the user’s approval. Microsoft could not patch this
<-QUOTE}
Hm, I wonder how such an attack could be performed. Although I'm running Vista in a VM I'm not a Vista or UAC expert because I hardly use it. Thus, I might overlook something - but only shatter attacks come to my mind (aside from flawed 3rd party software). However, those attacks were a problem in XP but are no longer possible in Vista as a secure desktop is used by UAC.

Another important issue is the following one mentioned here (http://www.tweakuac.com/uac-quiet-mode/):
{QUOTE-> What many users don't realize is that if they allow the program to run just once with the full administrative privileges, it becomes the "point of no return": from that moment on the software is free to do whatever it wants to the computer and no UAC messages will be displayed anymore about that particular software or any changes it makes to your system, even if UAC is fully enabled. The software can quietly install a keyboard hook to intercept your passwords, it can get full access to your files and documents (even if you keep them encrypted with the EFS system or Bit Locker), it can install itself to autostart automatically with full administrative rights every time you log on to Vista, and again, Vista UAC will NOT tell you anything about any of the bad things such software can do. <-QUOTE}
This alone justifies the use of a standard account in Vista, IMHO. Even if you installed software you deemed trustworthy (but isn't in reality) a standard account might prevent further damage done by this malware if started only with limited rights.

[softtouch]

If I would write a trojan or virus, I would have it trigger elevation, by either the file name (install, setup or update in the name) or with a manifest in the resource of the exe. I would encrypt the virus, and give it a nice name.
I then would upload it to a shreware site.
Somebody will download it, and will run it. And he/she will allow to install it. Elevation will be triggered, and after that I can do whatever I like...

[sukarof]

{QUOTE-> If I would write a trojan or virus, I would have it trigger elevation, by either the file name (install, setup or update in the name) or with a manifest in the resource of the exe. I would encrypt the virus, and give it a nice name.
I then would upload it to a shreware site.
Somebody will download it, and will run it. And he/she will allow to install it. Elevation will be triggered, and after that I can do whatever I like... <-QUOTE}

Disregard about Linux and other OS´s. (though if the malware producers would put their energy on the other OS´s you would have the same problem)
What is your suggestion for protection to a average user under those circumstances? How would anything prevent that kind of malware?
Lets say malware that steals your private data or makes a bot of your machine?

[tlu]

{QUOTE-> Disregard about Linux and other OS´s. (though if the malware producers would put their energy on the other OS´s you would have the same problem)
<-QUOTE}

I disagree. Most Windows users neglect the fact that Linux users hardly ever have to download software from 3rd party websites since virtually any software they ever need (including security updates for these apps) are offered by the official repositories for the respective distro. This is one major reason why Linux is more secure than Windows.

[sukarof]

Sorry for the OT

[Bubba]

Before We get any further OT, let's do remember what this thread concerns, Standard Account vs Admin Account in a Windows environment. Those that wish to discuss Linux, Please do so in an appropriate thread.

[MrBrian]

{QUOTE-> Hm, I wonder how such an attack could be performed. Although I'm running Vista in a VM I'm not a Vista or UAC expert because I hardly use it. Thus, I might overlook something - but only shatter attacks come to my mind (aside from flawed 3rd party software). However, those attacks were a problem in XP but are no longer possible in Vista as a secure desktop is used by UAC.
<-QUOTE}Please see post #25.

{QUOTE->
Another important issue is the following one mentioned here (http://www.tweakuac.com/uac-quiet-mode/):
<-QUOTE}The author of that quote is right but, when you read all of the author's words at that link, doesn't seem to understand the practical difference between the user being given the choice to elevate vs. automatically elevating. By the way, the same risk is present if you elevate from a standard account. One advantage of a standard account is to lower the risk of system-level changes without a UAC prompt. Another advantage of a standard account over an admin account is that malware can access only data available to the standard user's account, instead of accessing data available in any user account on the computer.

{QUOTE->
This alone justifies the use of a standard account in Vista, IMHO. Even if you installed software you deemed trustworthy (but isn't in reality) a standard account might prevent further damage done by this malware if started only with limited rights. <-QUOTE}I believe that even when using an admin account, malware cannot, for example, write to the Windows folder in Vista without a UAC prompt, due to the use of integrity levels.

{QUOTE-> Disregard about Linux and other OS´s. (though if the malware producers would put their energy on the other OS´s you would have the same problem)
What is your suggestion for protection to a average user under those circumstances? How would anything prevent that kind of malware?
Lets say malware that steals your private data or makes a bot of your machine? <-QUOTE}Malware can do those two things without even needing admin privileges, which is a good illustration that other security measures are justified in Vista even if you're using a standard account.

[softtouch]

{QUOTE-> Please see post #25.
I believe that even when using an admin account, malware cannot, for example, write to the Windows folder in Vista without a UAC prompt, due to the use of integrity levels. <-QUOTE}

That's right. Even with the admin account, you get an UAC prompt when you try to write to the Windows or program Files folder.

The admin account is a limited admin account, the real admin account is a hidden account.

A problem for me is, that almost every program you want to install will install into the "program files" folder, and for that, you need to allow it. Once allowed, the program (which could be a virus or other malware) can do whatever it want to do...

It does not matter whether you run under limited user or limited admin user account. Once the UAC popup, nd you allow the installation, it can be too late.

I am myself a programmer, and some of my programs need to install DLL's etc., so I added a manifest which force windows to popup the UAC. If I would be bad, I would hide a virus inside my installer. Once the user confirm the UAC popup, I could take over the system.