|User Account Control in Windows Vista|
Under The Hood - A Good Idea Gone Bad
| 6:26 pm on May 5, 2008 (gmt 0)|
User Account Control in Windows Vista
Under The Hood - A Good Idea Gone Bad
by James Turner
I was invited to write a short article on this subject. What follows may not be of direct benefit to webmasters but should provide some useful insights.
What purpose does User Account Control serve?
Without UAC, if you log on as an administrator, all programs that you start will have administrator rights. For instance, your browser would have the authority, to stomp all over your program files, rewrite the registry and generally cause mayhem. But it's only a browser so why would you want to give it so much power? In these days of organised crime paying hackers to find vulnerabilities in browsers, it is crazy that a program such as a browser that has no need of administrator rights should be given them by default - that is indisputable. People who simply dismiss UAC as worthless should consider this carefully.
If UAC is active, most programs start without admin rights. If a program wants or needs admin rights, it must request them - hence the notorious UAC prompt.
How does User Account Control currently work?
In the discussion that follows, I will talk about "programs" and "processes". A program is an executable file such as Notepad.exe but a process is a single instance of a running program. For example, if you open two text files with Notepad two unique processes will be created.
- Each process has it's own memory and its own access rights.
- No process has direct access to any other process.
Often the distinction between a program and a process is unimportant, in these cases I will use the term "program" since it is more familiar.
Every process has certain rights and privileges when it starts - these are checked before it is allowed to make critical changes to the system. For example, to adjust the system time, a process must hold the SE_SYSTEMTIME privilege. If the required privilege is not held, it can be requested. In this example, if the process started with admin rights, the request will be granted allowing the time to be changed. The important point to note here is that rights and privileges are NOT the same.
- Rights are fixed when a process starts, they cannot be changed.
- Privileges are adjustable but are limited by the rights.
- When a privilege is requested, no dialog is displayed either informing the user or requesting authorization.
In fact, as things stand, having separate rights and privileges is as daft a brush - all it does it make life difficult for programmers it does not add one iota to security. However, let's introduce User Account Control and see what difference it makes.
Suppose I want to write a program called GlobalClocks that displays the time in various parts of the world. For completeness, I want to allow the user to change the system time directly. So, I create a button that opens a dialog and the user enters the new time. The program then requests the SE_SYSTEMTIME privilege and is refused! When UAC is enabled, even if the user is logged on as an administrator, the program will have started with the same rights as a standard user, so it is impossible to change the time.
- If a program needs admin rights it must request them when it starts, otherwise it's too late.
Simple programs may be able to work around this limitation by restarting themselves and requesting admin rights (causing a UAC prompt to be displayed).
- If a program running with admin rights launches another program, the new process is guaranteed to have admin rights whether it wants or needs them. Furthermore, no UAC prompt is issued.
- When a new program is launched, it is normal to specify a window handle to act as the owner of error message dialogs. This handle is also used in various bodges, including UAC. If the handle identifies a window that is focused, a foreground UAC prompt is issued, otherwise a background UAC prompt is issued (a flashing taskbar button). If a null window handle is used, documentation suggests that a background UAC prompt is issued, however, in actuality, a foreground prompt usually results (possibly a late-breaking change before Vista was released).
Also, programs can no longer store data in their own program directories since the whole "Program Files" directory is protected and requires admin rights to achieve write access. However, programs that are not Vista-aware (i.e. do not specify the rights required in the program manifest) are provided with so-called file-virtualization. Attempts to save files to the program-files directory will result in files being transparently saved elsewhere in a user-specific location. This means, different users can no longer share such files but no warnings are issued! A similar approach is used with the registry.
Also, if a program running with standard rights wishes to launch a program with admin rights, it must use the verb "RunAs" (unless the program is marked as always requiring admin rights). Unfortunately, the "RunAs" verb was already in use in XP!
How should User Account Control be implemented?
Now we know more or less how the existing UAC system works, this begs the question, "Could it be done better?" In the discussion below, I have tried to outline an alternative approach. Opinions may differ on what precisely is the best method, but it should become clear that the current system can be greatly improved upon.
- Processes should be able to ask for admin rights after startup. Indeed, processes should then be able to drop back down to standard rights again. Furthermore, an icon overlay (or other indicator) could be used on the taskbar and titlebars to indicate which processes currently have admin rights.
Given that the access rights of a process are nothing more than stored data, it should be possible to do this by creating a UAC manager that can manipulate that data and thereby change the rights of existing processes. This might require significant effort but would make life far easier for programmers and would effectively negate the need for items 2 and 3. Further benefits are also outlined below.
- Programs running with admin rights should be able to launch programs with standard rights (by using the verb "RunAsUser"). There should be no difficulty implementing this since it can be achieved in XP by using the "RunAs" verb (albeit by using a different user name).
This is a real headache at the moment. For instance, if an installer wishes to launch a program with standard rights when installation is complete, it must itself start with standard rights, launch another program with admin rights to perform the install, wait around invisibly for it to finish, collect instructions by some mechanism to discover what to launch, and then launch it - absolutely ridiculous. (Actually, there are at least two other ways this could be achieved, but that is probably the simplest method.)
- A new verb "RunAsAdmin" should be introduced. Also, the API function ShellExecuteEx should be provided with additional SEE_ flags to perform the same functions whilst using a standard verb such as "Edit".
- A foreground UAC prompt should be issued if the calling thread owns the current foreground window. This is a small technical point but would ensure that UAC prompts are correctly placed in the foreground or background.
- Ideally, programs should have write-access to their own "program files" subdirectory (but should not be able to change executable files). However, since this has been effectively broken in Vista, the benefits are now moot.
We should once again consider the exact purpose of UAC. It is to protect the computer against viruses and rogue software. It should be configurable so that some programs are launched with standard rights and others with admin rights. It is sensible that programs that connect to the internet do so with standard rights only. It is also reasonable that the user should be prompted when a new program requests admin rights.
So, bearing this in mind, an editable white-list of programs is required with instructions to permit or deny admin rights (or to prompt the user). Additionally, a warning should be issued if a program running with admin rights attempts to connect to the internet or if a program that is connected to the internet (or has been connected) requests admin rights. Currently, most UAC prompts serve to annoy the user and do not add anything to security.
Also, if a white-list is used (together with existing Vista strategies for detecting installers) there should be no significant obstacle to prevent this technology being implemented in Windows XP. This would be especially true if programs can request admin rights whilst running. In this case, any attempt to perform a restricted action could result in a UAC prompt with the option to grant the request, deny it, or terminate the program. Presumably, all security checks prior to performing restricted actions pass though a single function to determine if access is permitted, therefore, only this single function should need to be upgraded to display UAC prompts on demand - hardly a difficult problem. In this way, User Account Control could be applied to old software without breaking it. It could also be applied to individual privileges and even individual directories and registry keys by extending the information stored in the white-list. In this way, programs could run with only the rights they actually need. For instance, it should be possible to grant a program the right to change the time without giving it full access to the registry.
Data Execution Protection
If User Account Control were implemented along these lines, it would be sensible to include Data Execution Protection (DEP) as well. DEP is a hardware technology supported by modern CPUs that prevents data being unwittingly run as program code - this is the essence of so-called "buffer-overrun" attacks by hackers. Currently, DEP is switched off for all programs by default (because some will fail if it is switched on, and may do so very subtly). Instead, DEP should be enabled by default for all programs that connect to the internet. If a program for which DEP is switched off attempts to connect to the internet, a warning should be displayed with the option to refuse the connection and mark the program as requiring DEP. The user could then close and restart the program. A new manifest-statement that identifies programs as being DEP-aware should be introduced (but only programs that connect to the internet would need to use it).
Beyond User Account Control
Programs that access the internet could be restricted to "guest user" rights rather than "standard user" rights. This should make it impossible for a hacker to introduce code that is capable of adjusting the user startup (or program code) so even if an attack were successful, it should not survive beyond a program restart. Additionally, browsers could be adjusted so that secure pages always open in a new process (requiring a new window, not a new tab). This would mean that if a hacker managed to introduce a keylogger temporarily into a browser, it would be unable to access data entered in a secure page.
Another method by which criminals can breach security is by adding keyloggers, etc. to software that is then downloaded and installed.
For spyware to work, it must be able to monitor keyboard, mouse and/or internet activity. With the exception of core operating system components, few legitimate programs should ever need to install a global hook to monitor events such as keystrokes. Therefore, if any program does so, a discrete popup warning should be displayed immediately and thereafter whenever the computer comes out of standby, etc.
A similar approach is required when monitoring internet activity, however, users should be able to white-list firewalls such as ZoneAlarm that are published by Microsoft-approved companies. These changes would not break any existing software but would alert users to the presence of spyware thereby making it largely ineffective. It would also provide a reasonable warning to employees if their company installs legitimate monitoring software!
Additionally, if a discrete popup warning were displayed whenever outgoing email traffic was detected, users could be alerted to the presence of botnet software (used to send spam). Some email clients already implement a similar feature for legitimate outgoing email so this should not be a nuisance to users.
NB: Spyware installed at the device-driver level has to be tackled differently.
Conclusion - How would these changes be better for users?
The basic concept of User Account Control is good. Not all programs require admin rights (and those that connect to the internet should be denied such rights). However, it is clear that Microsoft have done the worst possible job of implementing it.
Currently, UAC prompts are unnecessarily annoying being almost invisible (by flashing a taskbar button) or totally "in your face". However, worse than that, often they are inappropriate. For instance, a UAC prompt is sensible before installing a program that may change the existing Windows configuration but a prompt before opening the registry editor is not (but would be sensible before critical changes are made). Also, assuming that there is no way for a program running with standard rights to remotely control a program running with admin rights, Windows Explorer could safely run with admin rights which would mean that UAC prompts should not be required at all to delete or rename otherwise protected files. Naturally, this could be controlled by the white-list discussed above. Currently, although you could open Windows Explorer with admin rights, doing so would negate all the benefits of UAC because all programs launched from Explorer would automatically have admin rights too - absolutely crazy.
For Windows 7, virtually all existing UAC code needs to be discarded and reimplemented roughly as outlined above. It would be straightforward to implement existing UAC features within the new system, therefore no compatibility issues with existing Vista applications should arise. Overall, this should make life easier for programmers so they can spend more time creating useful features. Moreover, it would be more flexible, more secure and should result is fewer prompts which can only be an improvement for users.
In addition, User Account Control needs proper explanation (and a new name such as "Program Access Control"). In order for it to work properly, people must understand what it is, what is does and why it is needed otherwise many people will simply click "Allow" making it almost worthless. To this end a DVD should be produced together with a short teaching schedule covering all the basics of computer security. This should be sufficient for adults to digest at home and could be the basis of perhaps three or four half-hour lessons for schoolchildren (followed by questions and discussion).
Further, if Microsoft are really serious about securing the internet, they must accept that earlier versions of Windows are simply not good enough, include this technology in Vista SP2/3 and XP ServicePack 4 and possibly offer a low-cost, lightweight and secure version of Windows for use on old hardware (Win2000 capable). Since Microsoft are working on a cut-down version of XP for the one-laptop-per-child project, this should not be a problem. Also, by extending the useful life of old computers, it should be good for the environment, it should help poorer countries, and it might even provide a useful additional revenue stream! . . .
| 3:40 pm on May 8, 2008 (gmt 0)|
UAC "shmooac" its going to take education to solve security risks and not software/hardware controls. People are gullible and thats the problem.
As far as old hardware, i say let it die. Modern PC's are much more power efficient in many ways than the beasts of yesteryear.
Spend the money on a 4850BE cpu, and 780g motherboard, a decent power supply and a 2.5 IDE disk (7200 rpm of course) and you have yourself a sub 300.00 PC that can play games, movies, surf the web and consume less power than trying to support a beast of a P3 or old P4 machine grinding away.
| 3:59 pm on May 8, 2008 (gmt 0)|
|For instance, your browser would have the authority, to stomp all over your program files, rewrite the registry and generally cause mayhem. But it's only a browser so why would you want to give it so much power? |
Q: Why would you be surfing the net (or doing any day-to-day work) while logged on as an administrator? That's what standard user accounts are for :-)
| 9:33 pm on May 8, 2008 (gmt 0)|
|processes should then be able to drop back down to standard rights again. |
This is not going to work because you cannot revoke rights on an open handle. If the handle for an object is open with high access rights there is no way to recall these rights as far as Win32 API is concerned. The RevertToSelf() (if I recall it correctly) works the other way round, allowing to lower permissions temporarily.
| 6:52 pm on May 9, 2008 (gmt 0)|
>>while logged on as an administrator
Because despite the promise, Vista is still incredibly annoying if you try to do anything other than surf from a limited account, and since I'm rarely just surfing... The brilliant User Annoyance Central makes this all the worse.
Once I turned User Annoyance Central off, my Vista computing experience was vastly improved.
Thanks JDTurner for this huge write-up. One can only hope that they do it better the next time around.
| 3:38 pm on May 11, 2008 (gmt 0)|
|Vista is still incredibly annoying if you try to do anything other than surf from a limited account |
This may or may not be Vista's fault. What kinds of things can't you do logged in as a standard user?
| 5:48 pm on May 12, 2008 (gmt 0)|
I may have to try turning it on again, but I muck around. There are all the folders it doesn't want to let you use. Installing programs is a hassle. I don't know, but it was just annoying me so frequently I couldn't take it anymore. Many (like 10-20) times per day i was being asked to click to approve this or that. it drove me insane.
Maybe now that my system is installed and more stable, not making big changes, it may not be such a problem.
I suspect it works great in a managed environment where there is a standard set of corporate apps that get put on the computer and they don't want you to add other stuff, so they do want you annoyed.
| 7:22 am on May 14, 2008 (gmt 0)|
The biggest annoyance for me was the UAC popups when accessing files and folders, these are almost constant for experienced PC users.
I had almost forgotten about UAC I turned it off so long ago. No viruses or spyware as far I should add. :-)
| 6:57 am on May 23, 2008 (gmt 0)|
I wonder whether anyone from MS read this post... ;)
|Microsoft admits Vista UAC prompts 'need work' [zdnetasia.com] |
Scott Charney, head of Microsoft's Trustworthy Computing division, admitted this week that Windows Vista's User Account Control (UAC) prompts are not intuitive and confusing to users.
In a video interview with ZDNet Australia at the AusCERT 2008 conference this week, Charney said Microsoft needs to make improvements around UAC.
"Clearly there is work that has to be done around the UAC prompts--in part because of user feedback that they get the prompts at times they don't necessarily expect them and it is not intuitive."
| 5:29 am on Jul 11, 2008 (gmt 0)|
Microsoft's TechNet has a new (to me) article about the UAC that some might find interesting:
| 5:35 am on Jul 11, 2008 (gmt 0)|
Why did "James Turner" register a new account at webmasterworld and post a long, anti-microsoft diatribe? This is not exactly unbiased commentary:
|if Microsoft are really serious about securing the internet, they must accept that earlier versions of Windows are simply not good enough |
compared to what?
| 9:28 am on Jul 11, 2008 (gmt 0)|
|Why did "James Turner" register a new account at webmasterworld and post a long, anti-microsoft diatribe? This is not exactly unbiased commentary. |
1) I was invited to write an article on the subject.
2) I have WW username, however, for an article of this depth, the anonymity of a handle is hardly appropriate.
3) I looked up diatribe but could not find a definition that fits.
4) Any bias I may have against Microsoft is based purely on experience as a user and programmer. I have never worked for Microsoft, its subsidiaries or its competitors.
Microsoft recognized that a security problem exists because most users are logged on as administrators. Unfortunately, the solution they came up with (User Account Control) simply was not thought through properly. Quite simply, it is deficient in every regard.
1) It is not as secure as it could/should be.
2) It is not as backward compatible as it could/should be.
3) It is not as user-friendly as it could/should be.
4) It creates enormous and unnecessary problems for programmers.
As a writer I can explain and inform, but I cannot guarantee that everyone will understand.
| 4:39 am on Oct 20, 2008 (gmt 0)|
Norton Labs [nortonlabs.com] has a replacement for Vista's User Account Control (UAC):
|The Norton User Account Control tool will replace parts of the Windows Vista UAC system. It will utilize the UAC security feature from the Windows Vista architecture, while simultaneously improving user-friendliness significantly. The tool prompts recommendations based on an assessment on the user-action i.e. the signature information of the executable. The tool also has a “remember me” feature that allows users to suppress future prompts from the same action. |
The goal of this tool is eventually build a white-list (as well as black-list) database on various administrative actions, and to enable users to make smart decisions without unnecessary prompts, using prompts only as a last resort. The prompt will provide users with as much information as possible, as well as recommendations on the action requested.
I've migrated away from the Symantec family of apps, but I might try running this on a virtual PC to see if it has any merit.