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.
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.
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.
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!