Microsoft officials already had made similar statements about former UAC issues. But I think this is the first article that is not just a marketing text. It explains in great detail why UAC actually is no security boundary. And this is not just about Windows 7; it also applies to Windows Vista:

From the perspective of malware, Windows 7′s default mode is no more or less secure than the Always Notify mode (“Vista mode”), and malware that assumes administrative rights will still break when run in Windows 7′s default mode.

As I read this, you can’t really improve security on a Windows 7 machine if you set it to “Always Notify mode.” This is the first time I’ve read something like this, but it is consistent with the whole article that discusses several ways that malware can outsmart UAC.

Someone who is new to this discussion might wonder why we need UAC at all. Russinovich leaves no room for doubt that UAC’s primary goal was to force developers to write applications that require only standard user rights. And this was also Microsoft’s only concern when the company introduced auto elevation in Windows 7:

Can an application developer inadvertently or trivially depend on administrative rights by leveraging auto-elevate?

Microsoft was quite aware that malware programmers could use the auto elevation feature, but this was not really an issue. The only thing that interested them was whether auto elevation would endanger UAC’s primary goal, which is to educate developers. Because auto elevation works only for applications that belong to Windows, and because it is most likely that developers would rather fix their applications to make them work with standard users rights instead of exploiting auto elevation, UAC’s primary design goal wouldn’t be endangered.

I also understand now why Microsoft didn’t introduce a feature that would allow users to create a white list of UAC prompt immune applications. I think it is even possible that Microsoft convinced Symantec not to market its UAC tool. If users can prevent badly programmed applications from constantly issuing UAC prompts, then how can you educate the developers?

In less friendly words: At the high cost of annoying its own customers, Microsoft introduced UAC to improve Windows’ security in the long run.

I guess that few companies out there can afford such a strategy. However, I always doubted that this was the plan in the first place. And Russinovich admits it:

While it was an early design goal of Windows Vista to use elevations with the secure desktop, Windows Integrity Mechanism, and UIPI to create an impermeable barrier—called a security boundary—between software running with standard user rights and administrative rights, two reasons prevented that goal from being achieved, and it was subsequently dropped: usability and application compatibility.

So UAC was originally planned as a real security feature and ended as an “educational feature” because the project failed. Can you imagine how badly Vista would have been bashed if Microsoft had pushed its original plan through? The compatibility and usability issues many Vista users experienced in its early days would probably be harmless compared to the ones with the Windows that Russinovich sketched here.

The main problem with Microsoft’s strategy is that this educational campaign won’t reach retired developers whose legacy applications will still be required for many years to come. Thus, the question is, do you, as an “innocent” Windows administrator, want to continue suffering under Microsoft’s educational measure? Knowing now that malware can outwit UAC easily anyway, you also could disable the UAC prompts.

You might object that Russinovich said only that UAC is no security boundary, but it is still a security barrier. A security boundary is an impenetrable security barrier. I don’t know if there is such a thing as an impenetrable barrier; however, UAC prompts certainly can prevent “legacy malware” from being executed. But such outdated malware probably will die out soon, and most antivirus tools can cope with it anyway.

As far as I am concerned, I finally disabled the UAC prompts on my own machine after reading Russinovich’s article. However, I definitely decided to complain anyway about these maddening UAC prompts whenever I meet a Windows developer. If you like, then you can follow my example and continue writing e-mails to software vendors complaining about UAC prompts. That way, UAC’s primary design goal still will be reached.

• The myth about the standard user in Windows Vista and Windows 7 (10)
• Windows 7 RC UAC security vulnerability: Auto elevation (5)
• The myths about so-called hidden built-in administrator account in Windows Vista and Windows 7 (3)
• FREE: Steel Run As – Let standard users execute with administrator rights (14)
• Windows 7 UAC vulnerabilities (1)

Darren Canavor, a Microsoft program manager wrote almost three years ago about Vista:

In Windows Vista we made numerous changes to our user account model. Standard users are now the default user type for new accounts created after initial setup.

Is this really true? I seriously doubt that.

First of all, the first account that is created when Vista is installed is a member of the administrators group. Most home users who bought computers with Vista pre-installed use this account. Therefore, the majority of all Windows users still have administrator privileges more or less in the same sense as with Windows 95 or MS DOS.

You might object that Vista’s UAC makes sure that administrators run with limited privileges by default. Whenever a Vista administrator launches an application it runs only with standard user privileges (medium integrity level). This is true and certainly a good thing. However, this doesn’t change the fact that most end users still work with administrator privileges on their Windows machine. All they have to do is to confirm a UAC prompt and everything is just like in the good old Windows 95 days.

There are new reports that the infection rate of Windows Vista is much lower than that of Windows XP. This might partly be attributed to UAC. However, the interesting questions is whether the UAC prompts helped to prevent infections? I believe that the UAC was never really designed to prevent infections with warning dialogs because most users are trained to confirm all kinds of popups anyway.

It is no secret that Microsoft’s main reason of introducing UAC was to force developers to program applications that only require standard user rights. No software vendor can afford to annoy customers with constant prompts. Now that the UAC is established we will see far less UAC prompts than after Vista’s release.

Moreover, the fact that Windows 7 by default will only issue a UAC dialog whenever a program tries to make changes to the system, but not if the user changes Windows settings, will further reduce the number of UAC prompts. So everything is perfect now? No more nagging UAC and still a secure Windows? I don’t think so. In my opinion, the silent elevation security hole in Windows 7 shows that the whole UAC concept is flawed.

The real problem is that most home users and also many end users in corporate environments are still administrators on their machines. This hasn’t changed with the introduction of UAC. It is the main reason why the number of Windows computers that are part of a botnet is increasing steadily. The guys behind these botnets are a lot smarter than those script kiddies who just use virus kits to create the next killer worm. These infected machines most likely don’t appear in Microsoft’s statistics because the botnet creators don’t just want attention like the script kiddies. Thus, they do everything not to be detected, in particular they don’t damage computers like old-fashioned computer viruses. I seriously doubt that UAC or similar technologies is an effective remedy against the rising threat of rootkits and botnets.

What has to be changed is that end users need to not be allowed to make system changes. Thanks to the Internet, this is possible. In the pre-Internet era, people went to computer shops and bought software in colorful cardboard boxes to install it at home on their computers. This is not necessary anymore. In fact, I don’t understand why software still has to be installed at all. The only reason why end users require administrator privileges on their machines is because they have to install software.

This is an outdated desktop model. In my view, Microsoft shouldn’t focus on gimmicks like the superbar, UAC modifications and XPMode. Instead, as the biggest software company, they should lead us into a new era where users only use computers but no longer have to administer them. Computer administration is the job of system administrators, but not of end users. New technologies such as application virtualization and rich internet applications made this possible. Microsoft only has to fully embrace these new technologies instead of fiddling around with an outdated desktop model. But please don’t get me wrong. I am not saying that the future belongs to web apps. I am still a fat PC.

• Saved Internet Explorer passwords (1)
• FREE: GFI WebMonitor – Web filtering for ISA Server (3)
• Thoughts about User Account Control’s (UAC) primary design goal (4)
• Windows 7 RC UAC security vulnerability: Auto elevation (5)
• The myths about so-called hidden built-in administrator account in Windows Vista and Windows 7 (3)

I really can’t believe that Microsoft just ignored Leo’s findings. Leo has contacted the company and offered his proof-of-concept program’s source code. Moreover, major news sites such as The Register have reported this issue; thus Microsoft must be aware of this serious security problem. This indicates that there is a design flaw in UAC that probably can’t be fixed easily. Therefore, it is quite likely that Windows 7 will be released with this vulnerability.

Leo has described the vulnerability in detail, so I am giving only a brief overview here. He has proven that any program running with standard user rights (medium integrity level) can elevate another program (high integrity level) without issuing a prompt if UAC is configured with the default setting. Basically, this makes UAC useless, because its main purpose is to warn users whenever a third party application tries to modify the system. However, it is obviously easy for malware to outsmart UAC and run its own code with administrator privileges, without the user’s approval.

Leo’s proof-of-concept tool demonstrates this issue very well. The program is a standalone application that doesn’t issue a UAC prompt when launched. I used the tool to run notepad with administrator privileges. Even though I saw no UAC warning dialog when notepad started, I could save a file in the Windows system folder with it.

Leo uses the auto elevation “feature” (also called silent elevation) that was introduced in Windows 7. This feature allows Windows to elevate some system tools silently, that is, without prompting a UAC dialog. The default UAC setting (“Notify me only when programs try to make changes to my computer”) enables silent elevation. For example, when you try to change the firewall settings, you will see a UAC prompt in Windows Vista, but auto elevation prevents this in Windows 7. Leo’s tool just uses these privileged Windows processes to execute his own code. Moving the UAC slider to the top, to “Always notify,” disables silent elevation. Therefore, this security vulnerability doesn’t exist at the highest UAC security level.

What I find interesting is that Leo doesn’t consider himself to be a hacker or security expert. In fact, the technique he used is fairly simple, using only standard APIs. He describes it as code injection, but acknowledges that this term is used differently sometimes. The point is that it is only a matter of time until others will find ways to use this Windows 7 vulnerability. My guess is that malware programmers are already prepared. The bad guys usually don’t go to the public.

I have argued right from the beginning, when UAC was introduced, that security prompts with such a high false-positive rate are useless, even dangerous, because they lull users into a false sense of security. With Windows 7 this becomes even worse than in Vista. Many users keep UAC enabled because they want to know when a program tries to make system changes. In Windows 7 this reason no longer applies. Of course, most will just work with the default UAC setting, with the false belief that Microsoft certainly knows which configuration is best.

Even Microsoft’s primary goal, i.e., to coerce developers to write applications that require only standard user rights, is in danger when circumventing UAC becomes common practice. I only hope that Microsoft will change the default configuration to the highest security level in Windows 7 RTM. At least this won’t put ideas into the heads of Windows developers.

For future releases Microsoft should adapt Symantec’s UAC approach and allow users to create white lists of applications that don’t issue UAC prompts. This would reduce the number of UAC prompts significantly. After users have trained UAC, the false-positive rate will be low enough to make UAC a useful security tool. It goes without saying that this method would provide more security than this silent elevation “bug” in Windows 7.

• Thoughts about User Account Control’s (UAC) primary design goal (4)
• The myth about the standard user in Windows Vista and Windows 7 (10)
• The myths about so-called hidden built-in administrator account in Windows Vista and Windows 7 (3)
• FREE: Steel Run As – Let standard users execute with administrator rights (14)
• Windows 7 UAC vulnerabilities (1)

But, this is not the topic of this post. It is about the “word of caution” at the beginning of the article. Sekhy, the author of the article, warns his readers not to “tamper around” with the Administrator account. Ever since Microsoft decided to disable the built-in Administrator account in Windows Vista, there is a myth about the magical powers of the “true administrator account” circulating on the net. Hence, those people who don’t really know about these true powers should not dare to use the supersecret administrator account.

There are myriads of articles on the web that explain how to enable the built-in Administrator account in Windows Vista. Usually they tell you the “command line trick” (net user administrator /active: yes) which makes the whole thing look like even more of a secret, that is, knowledge only real hackers have. (You probably know this other myth that “true administrators” work on the command prompt.) Usually these articles don’t tell you that the built-in Administrator account can also just be enabled through the Local Users and Groups snap-in or simply Computer Management, just like the Guest account which is also disabled by default. What I find interesting is that I wasn’t able to find one article that also tells you what these magical, super secret, true administrator powers are.

Well, there are indeed a few differences between members of the administrators group and the built-in administrator account. Let’s see how powerful they really are:

The built-in Administrator account and UAC (User Account Control)

Approval mode for the local Administrator account is disabled by default. There is a special Group Policy setting where this behavior can be changed: “Admin Approval Mode for the Built-in Administrator account”. Running Vista in Admin Approval Mode is nothing other than running Vista with UAC enabled. Hence, this simply means that UAC is disabled by default for the built-in Administrator account.

Of course you can change these setting also for all other administrator accounts by disabling UAC through the User accounts applet in the Control Panel or by disabling the policy “Run all administrators in Admin Approval Mode“. Note that this doesn’t just disable the UAC prompts like if you set the policy “Behavior of the elevation prompt for administrators in Admin Approval Mode” to “Elevate without prompting”. It disables UAC altogether, which basically means that every program an administrator launches will be elevated automatically. You can test this if you save a file with notepad in the Windows folder. If UAC is enabled you can’t do that if you didn’t elevate notepad before.

Thus the main difference between the built-in Administrator account and all other admins is that every program will run with elevated privileges. Since these default settings can be changed for the built-in admin account and the other administrator accounts there are no super secret powers involved here.

The local Administrator account and the “run as administrator” function

Another myth is that every time you launch a program with admin privileges it runs under the built-in Administrator account. I suppose Windows’ “run as administrator” function is the origin of this myth. The fact that you can use this function even if the local Administrator account is disabled should make it clear that there is no such connection between the two. You also can’t launch a program under the local Administrator account using the runas command line tool if this account is disabled. Perhaps the term “run as administrator” is a bit misleading. What this function really does is to run programs with elevated privileges or more precisely at the high integrity level, which can be done by every account that is a member of the Administrators group.

Modifying the built-in Administrator account

Another difference to other accounts is that the local Administrator account can’t be deleted. Moreover, you can’t remove this account from the built-in Administrators group. However, as noted above, it can be disabled which is the case by default. It is also possible to rename the local Administrator account.

Legacy applications and the built-Administrator account

There are some legacy applications that can only be installed or run using the built-in Administrator account. I haven’t encountered such an application for a while. As far as I know, this behavior has nothing to do with special capabilities of the local Administrator account; it is just a matter of bad programming. If you rename the built-in Administrator account and create a new one called “Administrator” these programs will just use this new account.

Basically the super powers of the Administrator account boil down to the differences with regard to the default UAC settings. As far as I know, there is nothing that can be done with the built-in Administrator account which can’t be done with a member account of the administrators group. Please, tell me if I am wrong.

By the way, Vista really has this super powerful account, just that it is not the built-in Administrator. It is the TrustedInstaller service (Windows Module Installer service), which can modify everything on a Vista machine, in particular system files. However, that is the topic of another story.

In one of my next posts, I will address a related myth, the myth about the standard user in Windows Vista.

• Saved Internet Explorer passwords (1)
• FREE: GFI WebMonitor – Web filtering for ISA Server (3)
• Thoughts about User Account Control’s (UAC) primary design goal (4)
• The myth about the standard user in Windows Vista and Windows 7 (10)
• Windows 7 RC UAC security vulnerability: Auto elevation (5)

When I first heard that Microsoft was going to introduce UAC in Windows, I thought it would be something similar to sudo in Linux. Unfortunately, UAC is no match at all for sudo. The feature I miss most is the ability to allow certain end users to manage specific operating system features that require administrator rights.

A typical example are the TCP/IP settings. Laptop users sometimes have to change their IP address themselves because some hotels don’ t use DHCP. The problem is that changing the network settings requires admin rights. Of course, you could just add the user to the administrators’ group; but this is something that responsible administrators try to avoid at all costs.

Steel Run As is not really comparable to sudo, but it can help you with similar problems. The tool has a simple GUI in which you have to configure the credentials of the administrator account, the command to execute and the working directory. Don’t forget the latter setting under Windows Vista. It seems one has to browse to the command; typing the path doesn’t work.

Steel Run As creates an executable that the user has to run. This program then launches the program that has to be executed with administrator rights. Note that the Steel Run As executable doesn’t contain the program that you want to run with admin privileges. This means that you also have to make sure that both the program and the Steel Run AS exe are available on the user’s computer. Steel Run As uses a cyclic redundancy check (CRC) to verify that the program hasn’t been altered. You don’t have to install Steel Run As itself on the user’s computer, though.

Also note that if UAC is enabled, you have to make sure that the program is elevated. Steel Run As doesn’t do that for you. Please check out my article about UAC elevation for more information about this issue. On Windows XP machines, you don’t to have to deal with this problem.

In one of my next posts I will show you how you can use Steel Run As to allow standard users to change the TCP/IP settings. You can take this as an example of how to use Steel Run As with batch scripts.

If you are an experienced admin you probably have found other workarounds for this Windows shortcoming. I am curious to know how you solved this problem.

Warning: Be careful with programs that allow user to open files. Users can open other programs with admin privileges this way. See comment below.

Update: Please, also check out my new article about RUNASSPC and CPAU, two comparable tools.

Steel Run As

• FREE: PhoneFactor – Mobile phone based two-factor authentication (1)
• How to disable USB drive use in an Active Directory domain (0)
• Service Account best practices – Part 2: Least Privilege implementation (0)
• Four fast ways to improve security in SQL Server 2008 R2 (12)
• Managed Service Accounts in Windows Server 2008 R2 (7)

The whole discussion is about the new UAC setting “Notify me only when programs try to make changes to my computer“. It is the default configuration what makes this issue even more problematic.

The first Windows 7 UAC vulnerability

The main point about the first vulnerability is that third party software is able to disable UAC without giving UAC the chance to prompt the user for consent. Rafael Rivera wrote a proof-of-concept VBscript program that demonstrates how malware could disable UAC. Basically, the program emulates a sequence of keyboard inputs that turn off UAC.

This is not invisible to the user though. If you start the script, you will see a couple of windows flare up, and at the end, Windows displays a systray notification that informs you that you have to “restart to turn off User Account Control”.

Microsoft’s response was that this is a feature and not a bug. The idea behind the default UAC setting is that the user won’t be bothered with a UAC prompt whenever they change a Windows setting. Because the UAC settings are obviously Windows settings, you should not see a UAC prompt when they are changed. Furthermore, in order for the malware “to have gotten on the box, something has already been breached (or the user has explicitly consented)”.

In my view, Microsoft’s arguments are not valid. The user’s only “explicit consent” would be to simply launch the program. But this is exactly the situation we now have in Windows XP. A user who belongs to the administrator group just has to launch malware to manipulate the system. Let’s assume that it is possible to write a program that is able to turn off UAC in the background without displaying anything on the screen (like the proof-of-concept code); I don’t see then how the default Windows 7 UAC setting brings any extra security compared to Windows XP. Hence, the default setting makes UAC more or less useless.

The only hope you have is that the malware is stupid enough not to disable UAC before getting to work. Since it is extremely easy to circumvent this obstacle, it’s like keeping your door unlocked and hoping that a thief might not know how to use a door handle.

The second Windows 7 UAC vulnerability

The second vulnerability is even more severe because it demonstrates that malware can outwit UAC without even having to disable it. When the default UAC setting is on, Windows 7 checks the embedded certificate of a program and whether the new autoElevate flag is set to decide if a UAC prompt is required or not. The problem is that there are a few Windows programs that have this autoElevate flag and also have the ability to launch other programs. Because Windows passes the administrator privileges from the parent process to the child process, malware can misuse these Windows programs to launch its own code having administrator rights without issuing a UAC prompt.

Rafael Rivera again wrote a proof-of-concept. He uses a proxy application, which he called Catapult.exe, that launches Cake.dll. With the default UAC setting, Windows will run Cake.dll with admin privileges without issuing a prompt. You can verify that if you set the UAC setting to “Always notify me”. If you start Catapult.exe with this configuration, you will get a UAC prompt.

Jon DeVaan responded to both issues in Microsoft’s Engineering Windows 7 blog. If I understand him correctly, then his main argument is that the term “vulnerability” is restricted to flaws that allow malware to get running without the user’s consent. If you explicitly launch a program that contains malware, you have already given your consent. Therefore, we should not talk about a vulnerability here. His other argument is that there are other new defense mechanisms in Windows 7 that prevent malware from getting on the PC on the first place.

The second argument sounds very strange to me. If you don’t lock the door of your flat because the house door is locked, then someone obviously wasted money on buying a lock for your door. Therefore, Microsoft wasted money on implementing this new UAC setting because it is rather useless. It also doesn’t make much sense to start a discussion here about the true meaning of the word “vulnerability”.

One thing is for sure, the default UAC setting in Windows 7 is a design flaw. Let me repeat what this setting is supposed to do: “Notify me only when programs try to make changes to my computer”. Obviously, UAC can’t keep this promise. In both the aforementioned cases, a program can make changes to my computer without a UAC prompt. Thus, the correct description of the setting would be “Notify me only when non-malware programs try to make changes to my computer”.

Update: Microsoft acknowledges the Windows 7 UAC flaw and will correct it in the Release Candidate

• Thoughts about User Account Control’s (UAC) primary design goal (4)
• The myth about the standard user in Windows Vista and Windows 7 (10)
• Windows 7 RC UAC security vulnerability: Auto elevation (5)
• The myths about so-called hidden built-in administrator account in Windows Vista and Windows 7 (3)
• FREE: Steel Run As – Let standard users execute with administrator rights (14)

NUAC’s setup asks you if you want to submit UAC prompts. This means that NUAC will send metadata about your actions to Symantec. This metadata contains information such as the filenames and the hashes of the executables and the DLLs involved in the action. Symantec intends to build a white and a black list for UAC prompts. I think this is an interesting idea. This technique works very well for SPAM and I believe it could improve security significantly on Windows PCs. If people know that a UAC alert has never shown up somewhere else, they will be extra careful. Moreover, UAC will be less likely to get on our nerves. Note that the current beta doesn’t use these lists yet.

NUAC is already a useful UAC extension. Its prompts have a “Don’t ask me again” check box, and the dialog box has a details pane which displays the location and the name of the application that caused the prompt.

What I like about Symantec’s solution is that the check box doesn’t just refer to the program that you are about to launch. NUAC will suppress future prompts only if you start the program in the same way. For example, if you launched the application through its desktop icon, NUAC will prompt you again if you start it from the command prompt. More important is that this also includes attempts by other programs that try to launch the application. Thus, disabling UAC for a certain action does not place the corresponding application at risk of unauthorized use by malware.

A downside of NUAC is that it doesn’t have an allow list like Smart UAC. That is, you can’t edit the stored actions. NUAC stores them in the Windows Registry under HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\SymConsent\Data. Each entry corresponds to a specific action. But the key names are encrypted, so you can’t easily assign actions to them. I tried some well-known hash codes to no avail. Thus if you want to remove a certain action from the allow list later, you have to keep track yourself of the NUAC entries by noting the Registry key names. Of course, you can also delete all keys in the Data folder, which means that you have to train NUAC again.

NUAC’s beta is free, but I fear the final product will cost something. Nevertheless, I prefer NUAC over Smart UAC simply because it impressed me as more reliable. I also like that it doesn’t disable UAC the way Smart UAC does. Instead, NUAC just extends Vista’s UAC.

Norton Labs UAC (NUAC)

• Thoughts about User Account Control’s (UAC) primary design goal (4)
• The myth about the standard user in Windows Vista and Windows 7 (10)
• Windows 7 RC UAC security vulnerability: Auto elevation (5)
• The myths about so-called hidden built-in administrator account in Windows Vista and Windows 7 (3)
• FREE: Steel Run As – Let standard users execute with administrator rights (14)

One of the features that’s missing with Vista’s UAC is the ability to disable UAC prompts for particular applications. Sometimes you have to configure a Vista feature that requires admin privileges several times because you want to try out something. That’s when UAC can really get on your nerves. Even more annoying are auto-starting apps that initiate a UAC prompt whenever you boot up. Why should I need to confirm that a program is trustworthy more than once?

Like Vista UAC, Smart UAC will prompt for consent whenever you launch a program that needs administrator rights. However, it uses other heuristics than Vista UAC. When I tried the tool, I encountered several UAC alerts that were caused by Windows programs that wouldn’t have been displayed with Vista UAC.

The main difference, however, is that Smart UAC’s dialog window offers two additional options: “Always allow every action of this program” and “Always deny every action of this program.” Smart UAC also has an allow list and a deny list which can be edited manually. Note that you have to always click on “Cancel” if you don’t want the program to start, even though you want to add it to the deny list.

Unfortunately, the deny option didn’t work when I tested the tool. Smart UAC correctly added the program to the deny list. But the application was then treated as if it were in the allow list, i.e., no prompts were issued and the program started with administrator privileges. Perhaps the error was related to my test environment. Please let me know whether you also experience this problem. The allow option worked fine, though. It certainly is the more important feature. I mean, if you don’t want a program to start, I’d suggest not clicking it.

The built-in malware scanner is supposed to detect 400,000 threats. It makes sense to combine UAC with malware protection. In a certain sense, UAC is just a dumb anti-malware scanner. Almost all of its alerts are false positives. But what do all these prompts mean if you click on “Continue” and the program contains a virus?

Even though Smart UAC seems to be a bit unreliable to me, the idea behind the program makes a lot of sense. I wish Microsoft would add similar features to Windows 7 UAC, but I’m afraid my wish won’t come true.

Next I will publish a review of Symantec’s UAC extension. Stay tuned!

Smart UAC

• Thoughts about User Account Control’s (UAC) primary design goal (4)
• The myth about the standard user in Windows Vista and Windows 7 (10)
• Windows 7 RC UAC security vulnerability: Auto elevation (5)
• The myths about so-called hidden built-in administrator account in Windows Vista and Windows 7 (3)
• FREE: Steel Run As – Let standard users execute with administrator rights (14)

• The number of applications and tasks generating a prompt has declined from 775,312 to 168,149
• The number of sessions with one or more UAC prompts has declined from 50% to 33% of sessions with Vista SP1
• Windows itself accounts for about 40% of all UAC prompts
• Windows components accounted for 17 of the top 50 UAC prompts in Vista and 29 of the top 50 in Vista SP1
• In one lab study we conducted, only 13% of participants could provide specific details about why they were seeing a UAC dialog in Vista

I think it was expected that the number of UAC prompts would decline for three reasons:

• Many disabled either UAC or just the prompts
• Microsoft improved UAC with Service Pack 1
• Software publishers adopted their applications

Mr. Fathi doesn’t say anything about the number of machines that have the UAC prompts disabled. I think this would be the most interesting data. Another reason why the number of prompts has declined could be that most users have configured their desktops by now. However, I think this argument is not valid, because Vista adoption is still growing fast.

Another number I am missing is the times UAC actually prevented malware from being installed on Vista. I have been using Vista since its beta release on several machines and, thus far, all UAC prompts were only “false positives.” But perhaps I’m not a good example, because malware very seldom manages to reach my computers. At least, my anti-virus software hasn’t triggered an alarm for ages.

I still don’t believe that prompts of any kind really improve security, because most users click them away without really being aware of it. Microsoft’s data confirms this. Also, UAC might lull users into a false sense of security. Not all malware requires admin privileges. Thus, UAC might reduce security in some cases if users believe that everything is okay as long as there is no UAC prompt.

I think Microsoft is quite aware of all this. It is no secret that UAC was mostly introduced to force developers to write secure software. No software publisher wants to annoy users with constant UAC prompts. This approach obviously worked. Hence, we admins should be very thankful to Microsoft. UAC is one of the major reasons why Vista got bashed heavily. It didn’t just annoy many customers with its prompts; it also broke many applications. Microsoft must have known this. But UAC is a long-term project. When more software vendors adopt their applications, it will improve security significantly in the long run. Hence, this was a necessary step Microsoft had to take even though it costs them market share now.

Most interesting certainly is how Microsoft will change UAC in Windows 7. Unfortunately, Ben Fathi isn’t quite specific here:

• Reduce unnecessary or duplicated prompts in Windows and the ecosystem, such that critical prompts can be more easily identified
• Enable our customers to be more confident that they are in control of their systems
• Make prompts informative such that people can make more confident choices
• Provide better and more obvious control over the mechanism

The first point is clear. But it remains to be seen whether there still is much room for improvement after Vista SP1. I don’t understand the second point. I don’t think security prompts will ever increase confidence in anything. More informative prompts might be helpful in some cases, but since most users don’t read UAC prompts anyway, this won’t change much with to regard to the user experience. The last point could be the most interesting one from an administrator’s point of view. I wished Mr. Fathi had revealed a little more here.

What I am really missing is a feature that allows me to exclude certain apps and users from UAC. Basically, I want all the features that sudo has under Linux. A su command that allows an admin to turn off UAC temporarily without hassle is also on my wish list. However, I doubt somehow that Microsoft will fulfill my wishes in Windows 7.

• What you have to know about Windows 7 SP1 and Windows Server 2008 R2 SP1 (0)
• What’s new in Windows 7 SP1 and Windows Server 2008 R2 SP1 (1)
• Poll results: Will you wait for SP1 before you deploy Windows 7? (8)
• Seven reasons why you need BitLocker hard drive encryption for your whole organization (16)
• Poll: Will you wait for SP1 before you deploy Windows 7? (4)

Shortly after this feature was first introduced, I always tried to think of a reasonable comment. But I have never needed to look up the reason why a server had to be rebooted. The problem is that Windows servers have to be rebooted so often, that it doesn’t matter anyway. However, I am sure this feature makes sense in some environments.

Before I wrote this post, I didn’t even know where these comments were logged. Well, of course, it is in the Event log. It seems the fastest way to look up shutdown and restart events is to set the event source to USER32 in the filter of the Event Viewer.

To turn off the Shutdown Event Tracker, you have to launch gpedit.msc and navigate to “Computer Configuration – Administrative Templates – System” and then set “Display Shutdown Event Tracker” to “disabled”.

If you would like to know more about the Shutdown Event Tracker, I recommend this article at techFAQ. You won’t believe how much can be said about this little feature.

Thanks Mike Azocar (Good to know that there are still Douglas Adams fans out there.)

• Thoughts about User Account Control’s (UAC) primary design goal (4)
• The myth about the standard user in Windows Vista and Windows 7 (10)
• Windows 7 RC UAC security vulnerability: Auto elevation (5)
• The myths about so-called hidden built-in administrator account in Windows Vista and Windows 7 (3)
• FREE: Steel Run As – Let standard users execute with administrator rights (14)

This is not only about disabling UAC, though. It is also helpful if you want to edit a file in the Windows or Programs directory. You probably know that you can’t just do that by opening the file through Explorer. If you try it this way, your editor won’t be able to save the file. It doesn’t help if you elevate Explorer before you open the file, either. The reason for this is that Explorer is already running, since the Windows desktop is also an Explorer process.

As noted above, one way to solve this problem is to kill the first Explorer process and then relaunch it with admin privileges. However, a better way is this:

1. Enable “Launch folder windows in a separate process” in the folder options of Windows Explorer: Press ALT, Tools -> Folder Options -> View. You only have to do this once
2. Close all Explorer windows. Note that there are also Windows apps that are based on Windows Explorer, for example the Control Panel. You have to close these, too
3. Launch Windows Explorer as administrator: Right click on the Windows Explorer icon and navigate to “Run as administrator”

Now you will be able to launch elevated apps from Windows Explorer. For example, you will be able to edit files in the Programs folder by opening them from Windows Explorer. Also, if you are starting an application from the Start Menu or desktop that has to be elevated, you won’t see a UAC prompt.

After you finished with your administrative tasks, you have to close ALL Explorer windows again. It is not enough if you just close the first Windows Explorer you launched explicitly as administrator. Once you’ve done this, UAC will be back to normal, and it will get on your nerves as usual.

Gosh, I am starting to like UAC. It is fun to fool around with it.

• Thoughts about User Account Control’s (UAC) primary design goal (4)
• The myth about the standard user in Windows Vista and Windows 7 (10)
• Windows 7 RC UAC security vulnerability: Auto elevation (5)
• The myths about so-called hidden built-in administrator account in Windows Vista and Windows 7 (3)
• FREE: Steel Run As – Let standard users execute with administrator rights (14)

The trick is to elevate the desktop shell (explorer.exe), temporarily. Any tool that is launched from an elevated application will run with administrator rights. And best of all, UAC will not display its disturbing prompts from then on. The downside of this solution is that you have to kill the explorer process, first. You can just imagine the problems, it might cause. So I would recommend using this workaround with caution.

Here is how it goes. Create a batch file with the extension cmd with these two lines

Taskkill /F /IM explorer.exe start C:\Windows\explorer.exe

/F means that the task is killed forcefully, and /IM stands for the image name, i.e. the file name of the process. Be careful with the second line. I had a typo in it which left me with an empty desktop. In such a case you can launch explorer.exe with the Task Manager (CTRL+ALT-DEL -> File -> New Task (Run…)).

You have to run this batch file with admin privileges (right click on it and navigate to “Run as administrator”). The UAC prompt will just be displayed once. After that you won’t see it again in this session. Note that not only those applications where its icon contains a UAC shield will be launched automatically with admin privileges, but also those programs which should never be elevated (Internet Explorer for example).

Well, this is like in the good old XP times. You will again be the absolute master of your machine. What I find interesting is how easy it is to trick UAC. If malware manages it somehow to entice you to click just once on a UAC prompt, it will be the master of your computer from then on.

Unfortunately there is no easy way to switch back to standard user rights like under Linux. After you finished your administrative tasks you have to logoff and logon again. Please, let me know if you know of any other way.

Another option to turn off UAC is the TweaUAC. I could have sworn that before SP1, rebooting Vista wasn’t required. But when I tried it today, this didn’t work anymore.

• Thoughts about User Account Control’s (UAC) primary design goal (4)
• The myth about the standard user in Windows Vista and Windows 7 (10)
• Windows 7 RC UAC security vulnerability: Auto elevation (5)
• The myths about so-called hidden built-in administrator account in Windows Vista and Windows 7 (3)
• FREE: Steel Run As – Let standard users execute with administrator rights (14)

This poll is certainly not representative. 4sysops readers are more tech savvy than the average Vista user. They not only figured out how to disable UAC, they also install software and change system settings more often. Thus they get annoyed by UAC prompts regularly.

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

But these numbers surprised me anyway. I think this poll shows that more than 70% of IT pros reject UAC. I’ve been criticizing UAC ever since. I’ve read several times that one of the major reasons why Microsoft introduced UAC was because they wanted to encourage developers to distinguish between applications that need admin privileges and those needing just standard user rights. I wonder if this approach will work considering that the majority of IT pros disabled it anyway.

I am a supporter of separating administration work from ordinary Windows usage, but UAC is just a bad solution to this problem. Su/sudo under Linux is certainly a better one. However, that doesn’t mean that I recommend disabling Vista UAC. You can just turn the elevation prompts off and let UAC enabled. UAC improves security not only by asking for approval if an application changes important system settings. I blogged about the reasons not to disable UAC more than a year ago.

Another option is to use the free tool TweakUAC to disable UAC quickly when you have to do some tasks requiring administrator privileges. After you are done with your work, you can enable it again without hassle. This is already close to the su command under Linux. By the way, I just added TweakUAC to the list of free Windows management tools. So you can rate it now.

If there are just a couple of applications where UAC is getting on your nerves, you might use this little trick to get rid of the UAC prompts just for those aps. I think many disabled UAC not only because of the constant confirmation prompts, but also for compatibility reasons. In those cases it often helps to elevate an application manually. I listed eight ways to run a Vista application with administrator privileges.

The scripting guys might be interested in the Script Elevation PowerToys that allow you to launch PowerShell with admin rights from Windows Explorer and help you to elevate a tool on the command prompt. You can also rate them now. And here you’ll learn how to run VBScript or JScript scripts with admin rights under Vista.

• Thoughts about User Account Control’s (UAC) primary design goal (4)
• The myth about the standard user in Windows Vista and Windows 7 (10)
• Windows 7 RC UAC security vulnerability: Auto elevation (5)
• The myths about so-called hidden built-in administrator account in Windows Vista and Windows 7 (3)
• FREE: Steel Run As – Let standard users execute with administrator rights (14)

Turning off Vista UAC via the Control Panel is a bit longwinded. With TweakUAC, you can do this much faster. You just have to launch the tool with a mouse click.

You can also only turn off the UAC prompts with TweakUAC. This is not only more secure than disabling UAC altogether, you also spare the reboot. So if you have to do some admin work on a Vista machine, you can just turn off the UAC prompts and re-enable it when you are done with your work.

This tool is also useful for checking the UAC status on a Vista machine. You can just put it onto your memory stick, so you always have it with you.

• Thoughts about User Account Control’s (UAC) primary design goal (4)
• The myth about the standard user in Windows Vista and Windows 7 (10)
• Windows 7 RC UAC security vulnerability: Auto elevation (5)
• The myths about so-called hidden built-in administrator account in Windows Vista and Windows 7 (3)
• FREE: Steel Run As – Let standard users execute with administrator rights (14)

You probably know that you can launch a command prompt in Vista with the Windows Explorer by holding the shift-key and right-clicking on the folder where the commands you want to use are located. You will see the “Open Command Windows here” option in the context menu. This doesn’t work in the left navigation pane of Windows Explorer, though. By the way, the context menu will show another useful option this way: “Copy as Path“. It allows you to copy the corresponding path to the Windows Clipboard. This is sometimes useful if you need a directory path on the command line or in a script.

If you start a command prompt as described above, then Vista’s UAC will make sure that it will only be opened with standard user rights. With the Script Elevation PowerToys, you can add several new options to the context menu of Windows Explorer. To install them you have to right-click on the corresponding inf file and navigate to “install”.

The name of the inf files are self-explanatory. For example, after you installed ElevateComand.inf you will be able to launch elevated commands from the command prompt with elevate <application name>. You can also use this in scripts. The other inf files are for adding commands to the Windows Explorer context menu. For instance, installing PowerShellHereAsAdmin.inf will allow you to open an elevated PowerShell prompt by right-clicking on a folder in Windows Explorer. CmdHereAsAdmin does the same for Vista’s command prompt.

Some background on how the Script Elevation PowerToys work can be found in this TechNet article.

• Change the local administrator password on multiple computers with PowerShell (2)
• Query and kill a process on a remote computer using PowerShell and WMI (0)
• VBScript vs. PowerShell (0)
• PowerShell tutorial for admins – Part 6: Managing server roles and features (0)
• PowerShell tutorial for admins – Part 5: Using PowerShell Scriptomatic (0)

I must admit that for now, I am not so much disturbed by the UAC prompts anymore. I suppose, this is due to the fact that UAC has already trained me very well. So I usually don’t even notice the confirmation requests. I became aware of this when I worked with Windows Server 2008 because the prompts seem to pop up not as frequent as under Vista. So I always felt like something was missing. There are certainly good reasons not to disable UAC.

To date however, I didn’t encounter any case where Vista’s UAC really prevented malware from starting on my computer or other Vista machines in our network. You could say that the false positive rate is exactly 100%. Do you know of a positive case? If you don’t, then maybe you know of someone who did. Or maybe you know somebody whose grandmother has a cousin who heard of someone in the neighborhood who has a sister who didn’t have anti-virus software installed and who almost were infected by a virus, if not, well, a UAC prompt saved her day.

Please, don’t get me wrong. I fully support the idea behind UAC. Even IT pros shouldn’t logon as administrator, if they just want to read their mail or surf the web. My point is that Vista’s UAC is a bad solution to this common Windows problem. Why do I have to confirm it twice if I just want to move a desktop icon to the Recycle Bin? And why doesn’t Vista have an su command like UNIX that allows you to switch to administration mode whenever you have to administrate a PC?

I hope I didn’t influence your answer for this poll. Just let us know if you already disabled UAC altogether or if you disabled the confirmation prompts only. With the latter’s setting, UAC would still be running in the background, but it won’t prompt you if an application is about to be elevated.

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

• Thoughts about User Account Control’s (UAC) primary design goal (4)
• The myth about the standard user in Windows Vista and Windows 7 (10)
• Windows 7 RC UAC security vulnerability: Auto elevation (5)
• The myths about so-called hidden built-in administrator account in Windows Vista and Windows 7 (3)
• FREE: Steel Run As – Let standard users execute with administrator rights (14)

• Thoughts about User Account Control’s (UAC) primary design goal (4)
• The myth about the standard user in Windows Vista and Windows 7 (10)
• Windows 7 RC UAC security vulnerability: Auto elevation (5)
• The myths about so-called hidden built-in administrator account in Windows Vista and Windows 7 (3)
• FREE: Steel Run As – Let standard users execute with administrator rights (14)

It lets you start a tool with Administrators rights with just a mouse click and best of all; you won’t see this ugly UAC prompt. Unfortunately, this option is a bit longwinded to set up. Essentially, you have to add a task to the Task Scheduler and configure it to run “with highest privileges”. Then you create a shortcut on your desktop referring to this task. SeanDaniel.com has a detailed description. Hey, I wonder if there is a PowerShell geek out there who can show us how to do this faster with a nice command.

By the way, if you believe in UAC’s ability to improve security, you should only do this with applications that really need admin privileges to work properly. You can also use this trick to start a tool with Administrator rights only when it is necessary. For example, you could create two shortcuts on your desktop pointing to PowserShell, one that elevates PowerShell and the other only launches it with standard user rights.

• Thoughts about User Account Control’s (UAC) primary design goal (4)
• The myth about the standard user in Windows Vista and Windows 7 (10)
• Windows 7 RC UAC security vulnerability: Auto elevation (5)
• The myths about so-called hidden built-in administrator account in Windows Vista and Windows 7 (3)
• FREE: Steel Run As – Let standard users execute with administrator rights (14)