Home arrow Security arrow Page 4 - Vectors

“Unsafe at Any Speed” - Security

Many of us who use use security products on our computers religiously are bewildered to find that we still get infected with malware. How does this happen? No matter what we do, our computers are constantly in touch with the vectors that carry malicious software. Thomas Greene explains what this means, and what we can do about it.

  1. Vectors
  2. Common Vectors
  3. Other Vulnerabilities
  4. “Unsafe at Any Speed”
  5. Defense
  6. Linux Services
  7. Becoming a User
  8. Read, Write, Execute
By: Apress Publishing
Rating: starstarstarstarstar / 3
February 02, 2005

print this article



Many, if not most, home PC users are working with a single-user edition of Windows, such as Windows 95, 98, or Me. There are also multiuser editions such as Windows NT, 2000, and XP. UNIX and its cousins, BSD and Linux, are also multiuser systems.

The multiuser environment offers several distinct security advantages and should always be preferred, even in the home, and even when there is only one user.

The chief weakness of a single-user system is that whoever sits at the keyboard is the administrator, capable of taking any action he pleases. He can install programs and delete files or wipe out whole directories; he can alter system settings with the same privileges as the owner. This is bad in two ways. First, anyone with physical access to the machine can reconfigure it and possibly destroy important data files, whether intentionally or accidentally. Second, when every user is automatically an administrator, any malware that the user might pick up will run with the administrator’s level of access—that is, with unlimited privileges. Similarly, any remote intruder will automatically have full system access as well.

However, when we run a multiuser system like Windows XP or Linux, we can limit the level of system access granted to each user, and so limit the impact of malware and malicious attacks. There are other benefits as well: parents can prevent children from altering system settings that restrict their freedom on the Internet, for example. Even if a child is given his own computer, a parent can set up an administrator account on that machine for himself, and a user account for the child with fewer privileges. Similarly, if one wishes to share a computer with housemates but does not want them to access one’s own personal files or install software or fiddle with system settings, one can assign them user accounts in which to work.

Even when you are the only user, running your computer from an unprivileged account is always safer than running it as an administrator, or as root in UNIX parlance. If your machine is compromised, the intruder will likely (though not certainly) gain only your lower system privileges and may therefore fail to assume much control. This is true also when malware is inadvertently installed; it too will have fewer privileges if it’s installed under a user account. When you need to perform administrative tasks, such as installing software or hardware or changing the system configuration, you can simply log in as an admin or as root and do whatever you please.

Properly set up, a multiuser system can prevent attackers both remote and local from manipulating files and settings, prevent children from exceeding their privileges, and reduce the effectiveness of malware and remote exploits. The best advice I can offer to readers with single-user systems is that they switch to a full-fledged multiuser environment such as Windows XP or Linux right away. The recommendations offered throughout this book are based on a presumption that readers are working with multiuser systems, because the inherent weaknesses of single-user environments cannot be overcome and will undermine the best efforts of even the most conscientious, security-minded user. A single-user system is “unsafe at any speed,” so to speak.

A New York Times article from August of 2003 by Ian Austen did a good job of advocating the multiuser environment on grounds that it allows parents to regulate their children’s computer activity and permits each user to customize his desktop. But the author failed to grasp the important security implications of the multiuser environment and made a serious blunder, noting that “Windows XP ... allow[s] owners to set up a password-protected account for every user. When a computer has a single user, the log-on feature of Windows XP can be a bit of a nuisance.1

It is far from a nuisance. It is, in fact, a significant security enhancement, and it should be exploited as such. Even when you are the only user, habitually logging on to an unprivileged user account will make all of your Web activity safer and reduce the impact of malware and scripts.

Admittedly, a multiuser system is no guarantee against exploitation. There are numerous remote and local attacks against both UNIX-compatible and Windows-based systems with which an attacker can increase his privileges, but we can, and should, at least make him work for it. It’s foolish, even negligent, to hand over administrative privileges at the front door. By habitually working from, and accessing the Internet through, a nonprivileged user account, we can frustrate a large number of unsophisticated attacks and a good deal of malware from the start. But just like firewalling, virus scanning, eliminating insecure proprietary software, and patching promptly, a multiuser system is no security panacea, though it is an important layer of defense. However, by assembling these layers and building on them, users can disappoint attackers, even fairly sophisticated ones.

It might seem that talking about vectors of infection and multiuser computing environments in the same chapter is an odd mix, but the two are well connected. This is because the security context, or the level of system access, that a user is granted affects the potential of malware and malware vectors such as browsers, e-mail, and IM clients to deliver and execute malicious code. It is generally, though not universally, true that we can limit the harmful impact of malicious code by limiting the user’s access to the system. This is a basic principle, and an important one, though it’s not foolproof. It is, however, a useful rule of thumb to keep in mind: generally speaking, an unprivileged user will run unprivileged malware. This is why even the owner and sole user of a system should always work from a limited-access account, except when performing administrative chores.

Single-user editions of Windows attempt to control code execution with so-called “security zones” for online clients like Internet Explorer and Outlook Express. Since everyone using the computer either already is an administrator or can become one with ease, the idea here is to categorize Web content and software providers and their products as trusted or untrusted. For example, Internet Explorer allows a user to choose Web sites from which content like JavaScript and ActiveX controls will be trusted. Content from untrusted Web sites can be assigned reduced privileges on the machine. Similarly, there are digital certificates testifying to the origins of software, which the user can choose to trust or not. The security zone approach might make sense on a single-user system in lieu of something better, but Microsoft has extended this band-aid approach to its multiuser systems, where it actually undermines the essential benefits of the multiuser environment.

Windows is designed to grant and deny system privileges to third-party software, and even to outside parties, based on preselected trust criteria. Digital certificates for Web sites and for software are proffered to persuade users that their trust criteria have been met. Meanwhile, the operating system is designed to trust code when Microsoft or the user trusts it or its provider, and this means that even users on a multiuser system can sometimes run or install powerful and potentially destructive code from an unprivileged account.

This approach is wrongheaded from the start. It is the user whose privileges should be regulated, not the provider of a service or a piece of software. By making it possible for a piece of code to be trusted automatically by the system, Microsoft has made it possible for software to exceed the privileges of the user who installs it and scripts to exceed the privileges of the user who runs them. Thus a malicious program, apparently certified by Microsoft with a digital certificate, can be installed by a user and the system will grant it access to the deeper layers of the kernel. Incredibly, not only is Microsoft still clinging to this slapdash security scheme left over from the days of Windows 9x, it’s actually expanding it in Windows XP and all future versions, and incorporating it into its Web services.

The new regime is called Next-Generation Secure Computing Base (NGSCB), or Palladium, a complicated, hence fragile, trust scheme meant to improve the level of confidence a user can place in a Web service or a piece of software by means of “improved” certification. (Actually, certification will become more complicated, though not necessarily better.) Unfortunately, this approach ignores the fundamental problem of allowing the system to trust code that the administrator has not approved, and even to exceed the administrator’s authority in these matters. You can see the problem: even a minor flaw in this scheme could allow malicious code to be trusted and permit it to operate at a low level regardless of who installs it. This completely undermines the security benefits inherent in a multiuser environment. It means that your security will only be as good as Microsoft’s grand trust scheme makes it, and considering Redmond’s history in this area, I wouldn’t put much faith in it.

Users should not be expected to know whose content can be trusted and whose can’t, or what code is safe to run and what isn’t. There are too many variables for anyone to make an informed decision every time some script is about to execute in a Web page or some program is about to install a plugin or an ActiveX control. The right way to do it is the way Linux does it: keep everyone, including the machine’s owner, in unprivileged accounts except when administrative tasks need doing. When the system doesn’t trust software or its provider based on preselected criteria, users needn’t worry about the origins and security implications of some Web script, ActiveX control, patch, or program file. The worst they can do is make a mess of their own home directories. They can’t make a mess of the entire system.

The simple way is often the right way, and this case is no exception. On Linux, if root installs a program, it will be trusted systemwide. If a user installs a program, it won’t be. Generally, a program installed by a user will have no impact outside his home directory. Similarly, if a user’s Web clients execute scripts, they too won’t have impact outside his home directory. That is the right way to manage permissions. Ideally, nothing a user does, or allows a piece of code to do, in an unprivileged account should affect the guts of the system. Ideally, only root can make decisions with systemwide implications. I say “ideally” because there are ways for attackers and some malware and scripts to get around these restrictions, but this is no reason to ignore the benefits. Even Windows users should take advantage of the security enhancements in a multiuser environment, in spite of the fact that Microsoft’s basic security scheme often gives them, and the code they execute, more privileges than they ought to have.

We’ve already done away with Internet Explorer and Outlook Express in favor of Mozilla, partly because the Windows security zone scheme is a failure. The company remains in denial of this fact because it’s stuck with a very old and very poor design reaching back to Windows 9x, which it has been patching and elaborating instead of finding ways to abandon in favor of simpler, and better, solutions. Security zones and trusted content are band-aid approaches to the fundamental problem with single-user systems: the fact that all users are administrators—an extremely foolish design that should never have been chosen in the first place. Microsoft’s original approach was bad enough, although, admittedly, there are limited options for controlling code execution in a single-user computing environment. But carrying this model forward into its multiuser systems, which would otherwise be a good deal stronger, and steadily building additional layers on top of a failed scheme that’s unsound in its footings, is pure folly that will cripple Windows security for years to come.

Fortunately, there are steps we can take to enhance the security of a multiuser Windows system and leverage its inherent superiority to earlier versions in spite of Microsoft. There is much to learn and much to do, but it can be achieved.

This chapter is from Computer Security for the Home and Small Office by Thomas C. Greene (Apress, 2004, ISBN: 1590593162). Check it out at your favorite bookstore today. Buy this book now.

>>> More Security Articles          >>> More By Apress Publishing

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Secure Your Business for Data Privacy Day
- Google Testing Security Fob Password Alterna...
- Security News Highlights Concerns
- Going to Extremes for Data Security
- Skipfish Website Vulnerability Scanner
- Critical Microsoft Visual Studio Security Pa...
- US Faces Tech Security Expert Deficit
- LAN Reconnaissance
- An Epilogue to Cryptography
- A Sequel to Cryptography
- An Introduction to Cryptography
- Security Overview
- Network Security Assessment
- Firewalls
- What’s behind the curtain? Part II

Developer Shed Affiliates


Dev Shed Tutorial Topics: