Windows 7 UAC

Sorry, but that just isn't true. Whilst we (at work) will re-image every machine that we deploy, I have of course played with most of the pre-imaged systems we recieve from Dell and Lenovo, none of them have UAC set to anything other than the default setting, where it WILL prompt for access to make any system changes.

You're, failing to understand. Please check the link I provided in my first post. There is a way to bypass this prompt entirely at the default setting, in software. It is trivially easy. This is the issue. Of course they will get a prompt normally. The point is that software can easily bypass the normal operation because of the whitelist (there is an example you can try yourself!). Do you really trust your security to virus writers just not exploiting this?

Edit: I'm not sure I can be bothered to respond to these posts in future. If you aren't going to even read the posts, why reply?
 
Last edited:
Fundamentally the difference for the users that this vulnerability concerns is not much.

It is either:

User downloads .exe, runs .exe and clicks Yes to UAC prompt and gets elevated.
-or-
User downloads .exe, runs .exe and it auto-elevates by itself anyway.

The type of laymen users that run as Admin have probably never ever clicked No to a UAC prompt.

Bizarrely, UAC's primary purpose is not actually security motivated. It was conceived as a way to force independent software vendors to write software which could run as Standard Users. UAC is Microsoft's long-term game plan to wean ISVs off of this admin-account dependency. It is working. Maybe in Windows 8 the situation will have improved to such an extent that Microsoft can afford to put UAC back to the full Vista-style level without as much (or any?) consumer backlash like they got with Vista.

Windows 7 is going very well for them at the moment. And the better it does the better ISV products will get in supporting Windows true security model properly.

The good thing is that there is nothing fundamentally wrong with the operating system. There is some politics involved in the "default configuration", as we're discussing. But that's all it is. If Microsoft wanted or needed they could ship a WU patch tomorrow to up the UAC level to full.

PS: A true OEM pre-install will run the same Windows post-setup wizard as a Retail install. OEM pre-install's shouldn't just boot straight to a desktop. If it does, it's not a true OEM pre-install.
 
Fundamentally the difference for the users that this vulnerability concerns is not much.

It is either:

User downloads .exe, runs .exe and clicks Yes to UAC prompt and gets elevated.
-or-
User downloads .exe, runs .exe and it auto-elevates by itself anyway.

The type of laymen users that run as Admin have probably never ever clicked No to a UAC prompt.
Well the trouble is other vulnerabilities come along, as with any software; and this known vulnerability can be exploited remotely (for example), which would have been completely moot if UAC was not easily bypassed at the default. It's just unfortunate imo, the decision shows a lack of foresight in this regard. Pre-UAC this was a pretty common reality, UAC could potentially have prevented nearly all of these scenarios in the future.

Bizarrely, UAC's primary purpose is not actually security motivated. It was conceived as a way to force independent software vendors to write software which could run as Standard Users. UAC is Microsoft's long-term game plan to wean ISVs off of this admin-account dependency. It is working.
Surely that itself is security motivated? What would be the point of going to so much effort forcing ISVs to change otherwise? I'm unclear on what you think their motives are with this. Surely all the bad press they received in the past because of security issues was the motivator?

The good thing is that there is nothing fundamentally wrong with the operating system. There is some politics involved in the "default configuration", as we're discussing. But that's all it is. If Microsoft wanted or needed they could ship a WU patch tomorrow to up the UAC level to full.
I'd say the practical difference of so easily allowing unrestricted admin permissions (because it is so easily bypassed by default) is more than "politics". Though, admittedly, it's not anywhere near the level of coming with no firewall enabled like XP pre-SP2.

I think it would have been a really good move if they provided security essentials by default too but that isn't really needed.

PS: A true OEM pre-install will run the same Windows post-setup wizard as a Retail install. OEM pre-install's shouldn't just boot straight to a desktop. If it does, it's not a true OEM pre-install.
It didn't just boot into a desktop either.
 
Last edited:
Surely that itself is security motivated? What would be the point of going to so much effort forcing ISVs to change otherwise? I'm unclear on what you think their motives are with this. Surely all the bad press they received in the past because of security issues was the motivator?

The motivator is that eventually they'll be able to release a Windows OS that is fully locked down - by default. Think of it like Vista's security model but multiplied by 3.

All that is preventing this happening today is the software compatibility issue. Microsoft are responsible for the smooth running of millions (billions?) of PCs worldwide. The default UAC settings in W7 are a reflection of that.

If things remain on this course (WRT to ISV products improving compatibility) you might find that Windows 8 can afford to push back up the UAC level and more.

Ultimately the effect of the W7 setting is not that much. As I keep trying to explain.

Remote exploitation of this vulnerability would be very difficult. The exploit depends upon being able to inject code into a Medium integrity level process (such as Explorer or most other desktop applications). Traditionally, desktop applications are not good candidates for remote exploitation. Almost all of Windows background services run with the System integrity level. It is these services which expose the greatest attack surface area for possible remote exploitation. Even that is more difficult now thanks to DEP and ASLR. But of course if you can exploit one of these services then you are already fully elevated anyway. So you wouldn't need to elevate using the trick we're discussing.

As I said before, W7 isn't the first OS to have a local privilege escalation vulnerability. It also isn't the first to have one "by design". It won't be the last that's for sure. Just take a look at Microsoft's closest competitor.

Keep in mind that Windows 7 only has a 2 to 2.5 year shelf life. This isn't the "hook an XP machine to a network and count to 60 seconds" scenario all over again.
 
With increased levels of UAC, wouldnt there be increased amounts of malware/virus/worm etc that are developed to get around UAC security?
 
In theory UAC would be excellent additional security, if the defaults were decent.

User Account Control (UAC) in itself, or in its most commonly used state i.e. the Protected Administrator (PA) account where the user is running in Administrator Approval Mode (AAM), its main purpose isn't security. Its primary focus is to force Independent Software Vendors (ISVs) to start writing their applications so they work correctly with standard user rights. Any security benefit you receive from running as a Protected Administrator is simply a side effect of this.

Mark Russinovich said:
The PA account was designed to encourage developers to write their applications to require only standard user rights while enabling as many applications that share state between administrative components and standard user components to continue working. By default, the first account on a Windows Vista or Windows 7 system, which was a full administrator account on previous versions of Windows, is a PA account.

*Snip*

When UAC is enabled, all user accounts—including administrative accounts—run with standard user rights. This means that application developers must consider the fact that their software won't have administrative rights by default. This should remind them to design their application to work with standard user rights. If the application or parts of its functionality require administrative rights, it can leverage the elevation mechanism to enable the user to unlock that functionality. Generally, application developers need to make only minor changes to their applications to work well with standard user rights. As the E7 blog post on UAC shows, UAC is successfully changing the way developers write software.

Mark Russinovich said:
Conclusion:

To summarize, UAC is a set of technologies that has one overall goal: to make it possible for users to run as standard users. The combination of changes to Windows that enable standard users to perform more operations that previously required administrative rights, file and registry virtualization, and prompts all work together to realize this goal. The bottom line is that the default Windows 7 UAC mode makes a PA user’s experience smoother by reducing prompts, allows them to control what legitimate software can modify their system, and still accomplishes UAC’s goals of enabling more software to run without administrative rights and continuing to shift the software ecosystem to write software that works with standard user rights.

Software vendors could take advantage of the auto-elevation mechanism in Windows 7 to gain administrator rights. However, if Microsoft thought that the default User Account Control setting in Windows 7 was going to truly undermine this, they wouldn't have shipped Windows 7 as they have done. Also, with Microsoft working closely with the software vendors, this really isn't going to cause as much as a problem some people seem to think it will, in my opinion.

Mark Russinovich said:
End users have been asking for Windows to provide a way to add arbitrary applications to the auto-elevate list since the Windows Vista beta. The commonly cited reason is that some third-party application they frequently use forces them to constantly click through an elevation prompt as part of their daily routine. Windows 7, just like Windows Vista, doesn't provide such a capability. We understand the aggravation, and there might be a legitimate reason that those applications can't run without administrative rights, but the risk is too high that developers will avoid fixing their code to work with standard user rights. Even if the list of what applications get auto-elevated was only accessible by administrators, developers might simply change their application setup program, which requires a one-time elevation, to add their application to the list. We've instead chosen to invest in educating and working closely with application developers to ensure their programs work correctly as a standard user.

In reality the defaults allow anyone to easily bypass it. It is still not at all comparable to *nix, BSD or pretty much any secure system.

Windows in its current form today, regardless of whether the user has User Account Control enabled or not, the user is still running as an administrator, which means anything running as them can also quite easily run in the administrator context. User Account Control is simply a stepping stone to make Windows a securer operating system. Sure, it raises the security bar slightly but not nearly as much as it's end goal of enabling users to run as a standard user by default which is hopefully what will happen in the near future when Microsoft ship the next versions of Windows.

This issue has been massively complained about since the beta. Nothing has been done. Further information
You can almost effortlessly write a virus that bypasses UAC at the default setting, defeating the point of it.

Quote from the linked site above:

"So the advice remains as before:

If you are using Windows 7 and want to be protected against silent elevation then turn UAC up to the highest level.

The above isn't entirely accurate and could mislead people. Malware can *silently* gain administrator rights regardless of whether you leave User Account Control in its default setting in Windows 7 or change it to the "Always notify" option i.e. Windows Vista's mode. If malware has infected a user's account and has been written to take advantage of the opportunities elevating presents, when the user needs to do an operation which requests (requires?) administrator rights and accepts the elevation dialogue, malware can then subsequently gain administrator rights as well. Or, malware can gain administrator rights by compromising a process running with administrator rights due to the shared state between the account running with standard user rights and processes running with administrator rights in that account.

Someone saying "If you are using Windows 7 and want to be protected against silent elevation then turn UAC up to the highest level." may mislead people into thinking as long as they follow the above advice, nothing will be able to gain administrator rights without the user being fully aware, which is not the case. The only real difference between the Windows Vista and Windows 7 default configuration is in order for something to gain administrator rights in Windows Vista, the user needs to have elevated.

Mark Russinovich said:
UAC-1-1.png


First, consider the elevation dialog itself. It displays the name and publisher of the primary executable that will be granted administrative rights. Unfortunately, while greater numbers of software publishers are digitally signing their code, there are those that aren't, and there are many older applications that aren't signed. For software that isn't signed, the elevation dialog simply shows the executable's file name, which makes it possible for malware already running in a users account and that's watching for an elevation of an unsigned Setup.exe application installer, for example, to replace the executable with a malicious Setup.exe without the user being able to tell (see Figure 1).

Second, the dialog doesn't tell the user what DLLs the executable will load once it starts. If the executable resides in a directory under the user's control, malware running with the user's standard rights can replace any associated DLLs in the location that the software will use. Alternatively, malware could use side-by-side functionality to cause the executable to load malicious versions of application or system DLLs. And unless a user vigilantly clicks the details button and carefully looks at the file path listed for the elevating executable, malware can copy the executable to a similarly named location, for example, \ProgramFiles\Vendor\Application.exe (note the missing space in what should be "Program Files"), where it could control what DLLs the application loads. In Figure 2, I've copied a component of Microsoft Network Monitor to the user-created C:\ProgramFiles directory that's controllable by the user and launched it.

UAC-2-1.png


Finally, for application compatibility, elevated applications share substantial state with the standard user environment that a malicious application could use to influence the behavior of an elevated application. The clearest example of this is the user's registry profile, HKEY_CURRENT_USER (HKCU). That is shared because users expect settings and extensions they register as a standard user to work in elevated applications. Malware could use shell extensions registered in HKCU to load into elevated applications that use any of the shell browsing dialogs, like File Open and File Save. Other kinds of state are also shared, most notably the Base Named Object namespace, where applications create synchronization and shared memory objects. Malware could take advantage of that sharing to hijack a shared memory object used by an elevated application, for instance, to compromise the application and then the system.

Inside Windows 7 User Account Control - ( All of the above quotes have been taken from this article )

Mark Russinovich said:
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.

Inside Windows Vista User Account Control

Though, we are taking a completely different direction with regards to User Account Control in assuming User Account Control is an anti-malware solution, which it is not. Mark Russinovich talked about the changes made to User Account Control in Windows 7 and clarifying the purpose of User Account Control along with addressing some of the concerns regarding the changes in the continuation session of his Windows 7 and Windows Server 2008 R2 Kernel Changes talk at the Professional Developer Conference. (The actual talk regarding User Account Control starts roughly a minute after the continuation session starts.)

Windows 7 and Windows Server 2008 R2 Kernel Changes

Windows 7 and Windows Server 2008 R2 Kernel Changes (Continued from 1:30 Session)

However, I would add to that advice:

If, on the other hand, you don't care about silent elevation then you should turn down UAC to Elevate Without Prompting -- so that UAC is still enabled but it never prompts you -- because the default level isn't buying you much except a few pointless prompts which can be bypassed by any program which wants to."

The advice above will leave users even less secure. Anything which requests administrator rights will be automatically granted them as opposed to things having to be specifically written to take advantage of the opportunities which allow it to gain administrator rights in either Windows Vista or Windows 7 default configuration.
 
People who turn off UAC are alittle ignorant in the fact that UAC is to protect files automatically running in full Administration mode.

Users of Windows 7 should learn how to overwrite files within certain system directories correctly without the need to turn off UAC.

No, Windows UAC should not have a white list as this means software writters could just automatically add to the whitelist therefore bypassing security alltogether with no promt.

A UAC promt is there to protect end users and Administrators from human error and lets face it theres too much human error within IT to start with.
 
Remember, you won't be prompted for application launches therefore your not protected at the software promt level. You won't have a clue when something launches in the background. Choose wisely.

I've ended up only moving it down a notch rather than switching it off now, truth be told it was the screen dimming that was bugging me the most as I have a mutli-screen setup and at night it's a bit full on everytime I was promtped, I didn't realise that that you could keep the UAC on but just remove the dimming.

I'm guessing that's all it does (remove the dimming) moving the UAC a notch down from defualt ?
 
I've ended up only moving it down a notch rather than switching it off now, truth be told it was the screen dimming that was bugging me the most as I have a mutli-screen setup and at night it's a bit full on everytime I was promtped, I didn't realise that that you could keep the UAC on but just remove the dimming.

I'm guessing that's all it does (remove the dimming) moving the UAC a notch down from defualt ?

What setting did you move it too?
 
You can turn off the screen dimming (this is called Secure Desktop). I have done this as well as it gets a bit annoying on a multi-monitor setup.

Local Security Policy -> Local Policies -> Security Options -> User Account Control: Switch to the secure desktop when prompting for elevation

Set this option to disabled.

This reason Secure Desktop exists is to prevent malware from "spoofing" the UAC dialog or modifying a real one. But, because Secure Desktop is the default, no malware authors have bothered to exploit the non-default setting. Which means, by and large, it is safe to use.
 
You can turn off the screen dimming (this is called Secure Desktop). I have done this as well as it gets a bit annoying on a multi-monitor setup.

Local Security Policy -> Local Policies -> Security Options -> User Account Control: Switch to the secure desktop when prompting for elevation

Set this option to disabled.

This reason Secure Desktop exists is to prevent malware from "spoofing" the UAC dialog or modifying a real one. But, because Secure Desktop is the default, no malware authors have bothered to exploit the non-default setting. Which means, by and large, it is safe to use.

Bare in mind Windows Vista Home Premium | Windows 7 Home Premium does not include gpedit.msc.
 
Back
Top Bottom