Windows 7 standard user vs admin

[vincenzo]

On a Windows 7 computer with only one user, is there any higher protection from malware infection to be gained by running as a standard user?

My understanding is that even when running as admin, the rights are not elevated until you allow the UAC elevation, so I am wondering if the unelevated admin is essentially the same as the unelevated standard user (again I am talking just from the standpoint of malware installation).

In my research I found it often said that the standard user can only make changes that affect his own user account, not the rest of the computer. But when you are the only user, that seems to be irrelevant. I read one article by a Microsoft designer that said there are many forms of malware that can do all their damage running completely in a standard user account, and sending back that user's credit card info, usernames, passwords, etc, to the bad guys.

I've got different Win 7 computers running both ways, and it seems like both ask for elevation equally often, the only difference being that the standard user needs to input a password.

So the question is, is there any advantage to being a standard user, from the standpoint of preventing malware installation (such as from driveby installations or from clicking a malicious attachment)?

Thanks

[xxJackxx]

In theory they should be very similar but I'm sure we'll hear from someone that can give us a good reason why the LUA is safer. I know I have found it much easier to change network settings with an Admin with UAC account than from a standard user account, so I am sure differences exist.

My bigger issue is that I have found that when you install or uninstall software (a process that requires elevation) that often it will ask it you want to launch the program or it will open a browser with a survey or sometimes ask to restart the explorer.exe process. When any of these things are launched by the elevated setup program, they inherit its admin level. I don't understand why there isn't a bigger movement to stop these vendors from launching elevated web browsers from their setup programs. Hello drive by.

[m00nbl00d]

Originally Posted by vincenzo

On a Windows 7 computer with only one user, is there any higher protection from malware infection to be gained by running as a standard user?

With the introduction of Windows Vista and 7, Microsoft made it much easier to use a standard user account, by only elevating when needed, via UAC. Therefore, there's no reason why you should not take advantage of the security it offers, for free (no additional costs, that is lol).

My understanding is that even when running as admin, the rights are not elevated until you allow the UAC elevation, so I am wondering if the unelevated admin is essentially the same as the unelevated standard user (again I am talking just from the standpoint of malware installation).

That's a myth. An administrator account with UAC is not the same as a standard user account. The reason for such is quite simple, actually: UAC is not a security tool; it does create boundaries, but it is not a security tool. And, it's already known malware to exist that is able to bypass it. So, think twice.

In my research I found it often said that the standard user can only make changes that affect his own user account, not the rest of the computer.

Correct.

But when you are the only user, that seems to be irrelevant. I read one article by a Microsoft designer that said there are many forms of malware that can do all their damage running completely in a standard user account, and sending back that user's credit card info, usernames, passwords, etc, to the bad guys.

It's not irrelevant to use a standard user account, even when you're the only user. (For example, I personally run different standard user accounts for different tasks, such e-mail client, general web browsing, sensitive tasks.)

As you already mentioned, if an infections occurs in one standard user account, it will be contained, as it won't spread to others (Excluding if the malware finds a way to escalate privileges, but that's another thing.)

I've got different Win 7 computers running both ways, and it seems like both ask for elevation equally often, the only difference being that the standard user needs to input a password.

So the question is, is there any advantage to being a standard user, from the standpoint of preventing malware installation (such as from driveby installations or from clicking a malicious attachment)?

Thanks

Yes, there is an advantage. But, don't solely rely on a standard user account to stop it all.

What version of Windows 7 you got? You could deploy a security policy either with SRP or AppLocker.

Also add dangerous applications under Microsoft EMET (It has been discussed in the forum, search for it.), like web browser, media players, pdf reader...

Add to that an antivirus like Microsoft Security Essentials, and you've got your self a pretty solid security setup, which only a mistake by you would result in something bad, IMO.

[vincenzo]

Thanks for the information, what you've said makes sense to me.

What I would still like to find out is the specifics of what additional protection (or reduced vulnerability) from malware is achieved when you are using an unelevated standard user account, compared to an unelevated admin account.

Thanks

Originally Posted by vincenzo

My understanding is that even when running as admin, the rights are not elevated until you allow the UAC elevation, so I am wondering if the unelevated admin is essentially the same as the unelevated standard user (again I am talking just from the standpoint of malware installation).

LUA is the "proper" and safest way to run in a Windows environment - definitely recommended, but as to your question, I believe there is truth to your assumption based on the following:

-http://technet.microsoft.com/en-us/library/dd835561%28WS.10%29.aspx

When an administrator logs on, two separate access tokens are created for the user: a standard user access token and an administrator access token. The standard user access token contains the same user-specific information as the administrator access token, but the administrative Windows privileges and SIDs are removed. The standard user access token is used to start applications that do not perform administrative tasks (standard user applications). The standard user access token is then used to display 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 unless a user provides consent or credentials to approve an application to use a full administrative access token.

A user that is a member of the Administrators group can log on, 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 7 automatically prompts the user for approval. This prompt is called an elevation prompt, and its behavior can be configured by using the Local Security Policy snap-in (Secpol.msc) or Group Policy.

Essentially, you are running applications with standard token under an administrator account, unless you deliberately allow consent for it to run with elevated (to administrative) privileges. m00nbl00d is right, however, that it's not a security tool and malware exists that can bypass it, but it does offer some security-like benefits, especially if you run it at the highest setting.

[m00nbl00d]

As a result, all applications run as a standard user unless a user provides consent or credentials to approve an application to use a full administrative access token.

Microsoft should have been asked: Do you promise to tell the truth, nothing but the truth? (Something like that.)

Originally Posted by m00nbl00d

Microsoft should have been asked: Do you promise to tell the truth, nothing but the truth? (Something like that.)

Ha, ha...right, it still ultimately comes down to the user who has full administrative control of their pc. Even running normally as a standard user, they could still decide to install the "necessary codec" needed to view the video when a possible distraction clouds their common sense

[Sully]

Is the real difference the need to pass credentials? So with LUA (admin) UAC just does its thing because it already has the admin token. But with SUA (standard user) UAC needs the credentials of an admin account member because the admin token does not exist in SUA. ??

Sul.

Originally Posted by Sully

Is the real difference the need to pass credentials? So with LUA (admin) UAC just does its thing because it already has the admin token. But with SUA (standard user) UAC needs the credentials of an admin account member because the admin token does not exist in SUA. ??

Sul.

Yes, I think you're right, that's the main difference.

[MrBrian]

On a Windows 7 computer with only one user, is there any higher protection from malware infection to be gained by running as a standard user?

Yes there is. The difference is that malware running in a protected admin account can write to locations that an elevated process can later read from.

From Inside Windows Vista User Account Control:

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

[vincenzo]

Thanks, MrBrian.

So according to the second paragraph, it seems that even Standard User accounts are somewhat susceptible to this way of being exploited, though not as much so as admin accounts.

This article was written back in the Vista era. Are we to assume that this weakness is still present in Win 7? One would think that Vista was used as a testing ground and that they could have tightened things up in Win 7. Using the recommended Fast User Switching instead of Over The Shoulder elevations seems like a lot of trouble when an admin task needs to be performed.

[MrBrian]

Originally Posted by vincenzo

Thanks, MrBrian.

So according to the second paragraph, it seems that even Standard User accounts are somewhat susceptible to this way of being exploited, though not as much so as admin accounts.

This article was written back in the Vista era. Are we to assume that this weakness is still present in Win 7? One would think that Vista was used as a testing ground and that they could have tightened things up in Win 7. Using the recommended Fast User Switching instead of Over The Shoulder elevations seems like a lot of trouble when an admin task needs to be performed.

You're welcome .

As far as I know, what's written there applies to Windows 7 as well.

I normally do admin-type stuff in my admin account. For those few situations where I want to stay in my standard account and yet run programs as admin, I use an elevated program launcher to avoid UAC prompts.

Originally Posted by MrBrian

For those few situations where I want to stay in my standard account and yet run programs as admin, I use an elevated program launcher to avoid UAC prompts.

I'm using the latest SuRun for that. It's awesome

[MrBrian]

Originally Posted by wat0114

I'm using the latest SuRun for that. It's awesome

Since SuRun-elevated processes are run within the same standard account (instead of using a separate admin account), I think that a "malware running in a standard account can write to locations that an SuRun-elevated process can later read from" issue might exist.

Originally Posted by MrBrian

Since SuRun-elevated processes are run within the same standard account (instead of using a separate admin account), I think that a "malware running in a standard account can write to locations that an SuRun-elevated process can later read from" issue might exist.

I'm not sure, because Surun can elevate the process in the protected "dimmed" window. Isn't this isolated from the rest of the system? I don't really know how it works in depth, only that I like the convenience, and as long as I keep malware out, I should have nothing to worry about.

[MrBrian]

Originally Posted by wat0114

I'm not sure, because Surun can elevate the process in the protected "dimmed" window. Isn't this isolated from the rest of the system?

What I'm referring to here is which account the SuRun-elevated process runs in - use Task Manager or Process Explorer or similar to find out. I believe that a process that SuRun elevates runs within the same standard account, unlike a UAC-elevated process. If this is the case, then maybe a SuRun user using a standard account faces a similar security disadvantage that a UAC-protected admin account without Surun faces. Namely, here is a Mark Russinovich quote from post #10:

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

So would this invented quote (not from Mark Russinovich) also be true?

SuRun-elevated processes are especially susceptible to compromise because they run in the same user account as the standard 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.

Originally Posted by MrBrian

What I'm referring to here is which account the SuRun-elevated process runs in - use Task Manager or Process Explorer or similar to find out.

This is a bit over my head, so here are screenshots of IMGburn run elevated with surun from my user acount and no elevation without surun...

The first is with IMGBurn elevated with Surun and the second is run as LUA without Surun.

[MrBrian]

Originally Posted by wat0114

The first is with IMGBurn elevated with Surun and the second is run as LUA without Surun.

Can you go into Task Manager, find imgburn.exe, and then look at column "User Name"? If you elevate imgburn with SuRun, I believe you'll find that the account for elevated imgburn.exe is the same standard account. Now try elevating imgburn with UAC instead, and check the "User Name" column again.

Originally Posted by MrBrian

Can you go into Task Manager, find imgburn.exe, and then look at column "User Name"? If you elevate imgburn with SuRun, I believe you'll find that the account for elevated imgburn.exe is the same standard account. Now try elevating imgburn with UAC instead, and check the "User Name" column again.

With it Surun elevated, there is nothing under the user column, but with it UAC elevated, it shows as Admin.

[MrBrian]

Originally Posted by wat0114

With it Surun elevated, there is nothing under the user column, but with it UAC elevated, it shows as Admin.

Thank you.

Here's a quote from the SuRun readme.txt:

If a program needs administrative rights, the user starts "SuRun <app>". SuRun then asks the user in a secure desktop if <app> should really be run with administrative rights. If the user acknowledges, SuRun will start <app> AS THE CURRENT USER but WITH ADMINISTRATIVE RIGHTS.

I installed SuRun in a virtual machine. Then I SuRun-elevated a command prompt and typed whoami and got the response that I expected - the same standard account.

Originally Posted by MrBrian

Thank you.

Here's a quote from the SuRun readme.txt:


I installed SuRun in a virtual machine. Then I SuRun-elevated a command prompt and typed whoami and got the response that I expected - the same standard account.

Okay, so I guess it's only the surun-elevated app that is elevated with administrative rights within the user account, which is basically how I've understood it, or am I overlooking something?? I just checked the Task Manager->Properties->Security tab of mbam.exe being surun-elevated in my Win7 VM (VMWare Workstation) user account and it shows users as having "Read & execute and Read" rights only, whereas Admin having Full control. Surun.exe and Surun32.BIN also show users as having those same rights as well with mbam.exe elevated. I'm still confused on the danger here?? Does it mean the Surun-elevated process (in this case mbam.exe) can write to sensitive places where it normally should not be able to? If it's to admin locations, I can understand this, because this is the same, is it not, for UAC-elevated processes?

[MrBrian]

Originally Posted by wat0114

I'm still confused on the danger here?

I'm wondering about this scenario:
a) malware running in standard account writes executable file to some places where a standard account can write to
b) user elevates program with SuRun
c) SuRun-elevated program loads executable written in step a.

Originally Posted by MrBrian

I'm wondering about this scenario:
a) malware running in standard account writes executable file to some places where a standard account can write to
b) user elevates program with SuRun
c) SuRun-elevated program loads executable written in step a.

Oh I see what you're saying. Well, I'm not sure if that executable will run with admin rights or limited rights, because I think surun will only garner admin rights to the process it directly elevates?

[MrBrian]

Originally Posted by wat0114

Oh I see what you're saying. Well, I'm not sure if that executable will run with admin rights or limited rights, because I think surun will only garner admin rights to the process it directly elevates?

I'll give an example that Mark Russinovich used: "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." So if malware writes a shell extension for the current user, and you run a SuRun-elevated program that uses the common file dialog, the malware shell extension will run with full admin rights.

[MrBrian]

Originally Posted by vincenzo

In my research I found it often said that the standard user can only make changes that affect his own user account, not the rest of the computer. But when you are the only user, that seems to be irrelevant. I read one article by a Microsoft designer that said there are many forms of malware that can do all their damage running completely in a standard user account, and sending back that user's credit card info, usernames, passwords, etc, to the bad guys.

Some relevant reading material:
Security design: Why UAC will not work
Computer security: Why have least privilege?