Reg Review We evaluated the security features of Windows XP SP2 on a test machine, following a clean install of XP Pro with no configuration changes and no third-party software or drivers installed. We installed XP with the NTFS file system, choosing all of the factory defaults, then patched it with each recommended security update including SP-1 (required), before installing SP2.

While we found that there are indeed a few minor improvements worthy of acknowledgment, in particular, some rather low-level improvements that don't show to the admin or user, overall, SP2 did little to improve our system's practical security, leaving too many services and networking components enabled, bungling permissions, leaving IE and OE vulnerable to malicious scripts, and installing a packet filter that lacks a capacity for egress filtering.

The new Security Center utility with its frequent Security Alert popups will certainly give users the impression that SP2 is a security-oriented package, as Microsoft's PR boilerplate promises. However, The Security Center does little beyond warning users that the firewall is disabled, that automatic updating is disabled, or that antivirus software has not been installed. It may look impressive, but the SP2 package fails to provide several of the most important, basic modifications required to run Windows safely on an Internet-connected machine.

Windows Services

Microsoft has long enabled a number of services related to networking by default, most of which are unnecessary, even dangerous, on Internet-connected machines, and all of which a competent admin should know well enough to enable as necessary. Turning them on by default is a minor inconvenience to admins, who need to disable what they don't need (but usually know how to go about it), and a major source of trouble for home users, who can't be expected to know what services they do and don't need, or how to harden their systems by disabling superfluous ones.

SP2 does disable a few Windows services related to networking that have not previously been disabled by default, which certainly is an improvement. Unfortunately, too many services remain. And home users are given short shrift.

According to netstat, our machine had the following services listening on the Internet by default:

• DCE endpoint resolution (epmap), port 135. This is basically the UNIX/BSD/Linux portmap daemon, and unnecessary on home machines.
• NetBIOS name service, port 137. This is the WINS (Windows Internet Naming Service) server for a NetBIOS network, and unnecessary on home machines.
• NetBIOS datagram service, port 138. This is used by the SMB (Server Message Block) browser service, and is unnecessary on home machines.
• Microsoft-ds (Server Message Block), port 445. SMB can run directly over TCP/IP, without NetBT by using this service, which is unnecessary on home machines.
• NetBIOS Session, port 139. This is used for Windows File and Printer Sharing, unnecessary on most home machines, and extremely dangerous on any machine connected to the Internet unless the owner knows how to run it securely.
• Error Reporting is on by default. However, there is no reason why a machine should phone home every time it encounters an error. This is better left disabled.
• Automatic Update is off by default. Microsoft would very much like everyone to enable it, and now urges users to do so every time Windows Update is run manually; but it is never a good idea to let a third party decide what software should be installed on your machine, or when. This service should remain off, and users should update Windows manually, though regularly, paying attention to the various update options and their relevance to one's system.

Looking alphabetically at the Services dialog, we encountered the following settings (Note: "manual" means that the service will be started if invoked by a user, an application, or another service, while "automatic" means that it will be started at boot time whether it's needed or not).

ClipBook (used to store information, cut / paste, and share it among computers) disabled. About time.

DCOM Server Process Launcher, automatic. The process launcher implies that DCOM is enabled, as indeed it is (more below).

DHCP Client, automatic. Unnecessary on most home machines. Should be disabled by default.

DNS Client, automatic. Unnecessary on most home machines. Should be disabled by default.

NetMeeting Remote Desktop Sharing, manual. Unnecessary on most home machines. Should be disabled by default.

Network DDE, disabled. About time.

Network DDE DSDM, disabled. About time.

Remote Access Connection Manager, manual. Unnecessary on most home machines. Should be disabled by default.

Remote Desktop Help Session Manager, manual. Unnecessary on most home machines. Should be disabled by default.

Remote Procedure Call (RPC), automatic. This is one of Microsoft's greatest security holes. RPC enables one machine to execute code remotely on another. On UBIX/BSD/Linux, it can be disabled safely. On Windows, it cannot be disabled, as MS has made a plethora of necessary services dependent on it. It's a huge security hole that simply cannot be avoided. It must be blocked by a firewall.

Remote Registry, automatic (allows remote users to make Registry changes). Unnecessary and dangerous on most home machines. Should be disabled by default, and enabled only as needed.

Routing and Remote Access, disabled. About time.

Secondary Logon, automatic (enables starting processes under alternate credentials). Unnecessary on most home machines. Should be disabled by default.

SSDP Discovery Service (UPnP discovery), manual. Unnecessary on most home machines. Should be disabled by default.

TCP/IP NetBIOS Helper, automatic (enables support for NetBIOS over TCP/IP (NetBT) service and NetBIOS name resolution). Unnecessary on most home machines. Should be disabled by default.

Telnet, manual. Unnecessary on most home machines and company workstations. Extremely insecure. Should be disabled by default. Those foolish enough to use it can enable it.

Universal Plug and Play Device Host, manual. Unnecessary on most home machines. Should be disabled by default.

WebClient, automatic (enables Windows-based programs to create, access, and modify Internet-based files). Unnecessary on most home machines. Should be disabled by default.

Additionally, DCOM (Distributed COM) is enabled by default. It is unnecessary on most home machines, and should be disabled unless needed. It's the component that the Blaster worm exploited to get at RPC.

Networking components

In addition to services, Windows also installs a number of networking components that are unnecessary on the vast majority of machines, especially home machines. SP2 has done nothing to change this.

Most home users don't know that TCP/IP is the only networking component needed for an Internet connection to work. Nevertheless, Client for Microsoft Networks, File and Print Sharing, and the QoS Packet Scheduler are all installed by default, and SP2 does little to address these issues - although, presumably, file and print sharing are limited to machines on the same subnet. At least we hope so.

Furthermore, NetBIOS over TCP/IP is enabled, and that is never a good thing on home machines.

Most absurdly, Remote Assistance ("allow script kiddies to control this computer remotely?") is enabled by default, as is Remote Registry ("allow script kiddies to modify your Registry remotely?"). The Remote Desktop "feature" was off, thankfully.

Windows Firewall

The new "Windows Firewall" packet filter is turned on by default, finally. However, an exception for Remote Assistance connections is enabled, which is preposterous, although file and printer sharing, and UPnP, are blocked by the firewall as they should be. The putatively new "Windows Firewall" is actually not much different from its predecessor, the "Internet Connection Firewall", with all its weaknesses. Indeed, the only improvements are that the Security Center pops up a warning if the firewall is turned off, and the firewall alerts users to software willing to accept an outside connection.

Most importantly, the new packet filter, like the old, is incapable of egress filtering, although there were numerous press reports predicting such a capacity before its release, perhaps due to aggressive blogging by overeager MS shills. This particular omission is one of the greatest disappointments in SP2.

Because of the vast amount of malware, spyware, and adware plaguing Windows, it is crucial that a packet filter warn users whenever a program attempts to send data to the Internet. SP2 is of no value in this regard. It does, however, warn users of third-party clients that will accept incoming connections, and offers users an opportunity to block or enable them individually.

Nevertheless, Windows users must monitor outgoing connections, and must therefore continue to deploy a third-party firewall or packet filter capable of egress filtering in order to run Windows XP safely.

Policies

Default security policies with SP2 are basically sensible. However, there are exceptions. For example, to prevent NetBIOS null sessions, which are extremely dangerous, the Security Accounts Manager (SAM) should be configured to reject them. SP2 has done half the work. In the Network Access policy settings, the option "Do not allow anonymous enumeration of SAM accounts" is enabled, as it should be. Unfortunately, "Do not allow anonymous enumeration of SAM accounts and shares" is disabled, although it should be enabled. This arcane setting is not something that a home user should even have to know about, much less play with.

Permissions

If making Windows so dependent on RPC is one of Microsoft's greatest security stuff-ups, allowing Windows XP to be set up as a single user system is the most spectacular of all time.

Windows XP is the first genuine multiuser Windows system marketed to home users, yet Microsoft has stubbornly declined to enforce, or even encourage, its inherent security benefits. SP2 does nothing to improve the situation.

The chief weakness of a single-user system is that whoever sits at the keyboard is the administrator, or root in UNIX parlance, 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 files, whether intentionally or accidentally. Second, when everyone is automatically an administrator, any malware that a user picks up will run with the administrator's level of access - that is, with unlimited privileges.

Establishing less-privileged user accounts, even for the machine's owner, is the single most productive step one can take towards reducing the impact of malware. WinXP makes this possible, but, unfortunately, not necessary.

The level of system access that a user is granted affects the potential of malware, and vectors such as browsers, -mail, and IM clients, to deliver and execute malicious code. It is generally, though not universally, true that we can limit the impact of malicious code by limiting the user's access to the system. Generally, an unprivileged user will run unprivileged malware. This is why even the sole user of a system should always work from a limited-access account, except when performing administrative chores. UNIX-compatible systems enforce this worthwhile discipline strictly; Microsoft still does not even encourage it.

Internet Explorer

Windows attempts to control code execution with so-called "security zones" for online clients like Internet Explorer and Outlook Express. Since it's likely that everyone using the computer is an administrator, the idea here is to categorize Web content and software providers and their products as 'trusted' or 'untrusted.' Thus the user decides whether or not to allow provider X or Web site Y to run code on his machine, based on pure guesswork and vague impressions.

For example, Internet Explorer allows a user to choose websites from which potentially dangerous content like JavaScript and ActiveX controls will be trusted. Content from 'untrusted' websites can be assigned reduced privileges.

This approach is wrongheaded from the start. 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. And even when a user guesses right, malware can, and often does, execute in the wrong zone, as we have seen many times.

The default security settings for Internet Explorer are hardly changed from the risky and confusing ones Microsoft has been urging on users for years. Here's what we found:

ActiveX Controls: run and script functions are enabled by default if the control is "marked as safe". Downloading signed ActiveX Controls is enabled (no prompt), and unsigned ones are disabled (no prompt). Binary and script functions are enabled. This is far too confusing: ActiveX should have a simple on/off toggle, and should be kept off unless needed for something useful like Windows Update.

"Access data sources across domains" is disabled, and enabled for trusted sites. (We would leave it disabled.)

MetaRefresh is enabled. (We would leave it disabled.)

"Scripting of browser controls" is disabled for the Internet zone, and enabled for trusted sites. (We would leave it disabled.)

"Script initiated windows without size or position constraints" are disabled, but enabled for trusted sites. (We would leave it disabled.)

Drag & drop / copy & paste are enabled. (We would leave it disabled.)

"Installation of desktop items" gets a prompt, and is enabled for trusted sites. (We would require a prompt at all sites.)

"Launching programs and files in an IFRAME" gets a prompt, and is enabled for trusted sites. Most users probably have no idea what an IFRAME is. (We would leave it disabled.)

"Navigate sub-frames across domains" is enabled. (We would leave it disabled.)

"Open files based on content, not file extension" is enabled. (This is good.)

The pop-up blocker is enabled, but disabled for trusted sites. (We would leave it enabled.)

Userdata persistence is enabled. (We would leave it disabled.)

"Web sites in less privileged Web content zone can navigate into this zone" is enabled. (We would leave it disabled.)

JavaScript is enabled. (We would leave it disabled.)

"Paste operations via script" is enabled. (We would leave it disabled.)

Scripting of Java applets is enabled. (We would leave it disabled.)

In the Advanced dialog, things are fairly sensible overall, with a couple of exceptions:

"Check for server certificate revocation" is not selected. (We would leave it enabled.)

"Do not save encrypted pages to disk" is not selected. (We would leave it enabled.)

"Empty Temporary Internet Files folder when browser is closed" is not selected. (We would leave it enabled.)

Enable Profile Assistant is selected. (We would leave it disabled.)

Outlook Express

The chief security problem with OE has been that it defaults to viewing HTML automatically. Plain text should be the default, to cut down on Web bugs and malicious scripts. However, we find that little has changed with SP2:

"Automatically log on to Windows Messenger" is selected. Messenger should not be enabled on most company workstations, although at least now there is an option.

"Notify for each read receipt" is set. It would be better to turn receipts off, to avoid accidentally confirming one's e-mail address to spammers.

The send-format defaults to HTML, a great waste of bandwidth, and an irritant to people, like myself, who force their -mail to display as plain text.

The Outlook Express security settings are basically sensible. Potentially dangerous file attachments can be blocked from being saved or opened, and are in fact blocked by default. This feature is good, so long as the mail client knows what to look for. It can probably be fooled a number of ways, and certainly is no substitute for antivirus software.

"Block images and other external content in HTML email" is selected. This helps cut down on Web bugs and inadvertent spam confirmations. However, an HTML off-switch forcing all email to display as plain text would be a good deal more effective at this, and thwart malicious scripts to boot.

Conclusions

Microsoft declined many opportunities to harden Windows XP in a meaningful way; that is, by disabling unnecessary services, enforcing the multiuser environment, setting sensible user and file permissions, and installing a fully-functional packet filter. The roster of missing security utilities, such as PGP, SSH, a proper wipe utility, etc., is immense.

The home user is the one most in need of good security configurations and tools, yet the one least served by SP2. Windows may be easy to use, but it is extremely complicated and difficult to administer, especially for security, with a tremendous number of hidden functions and many complex configuration interfaces. It should be left to the professional admin to enable services and understand their dependencies, not left to the home user to figure out which ones are risky, and which ones can safely be disabled.

The Security Center is a good idea, but as it's been implemented, it's little more than a gimmick that will lead to a false sense of security. Our test system remained vulnerable to a vast host of online threats, especially those involving user interaction. And that's a pity, because a Windows system can be hardened significantly so that even careless users will have trouble infecting it - so long as one knows how to go about it. The idea behind SP2 was to apply the kind of security know-how that users aren't expected to have via a major system update, so that people can venture onto the Internet without worry.

Unfortunately, Windows remains a quite dangerous system to connect to the Internet, and users are still very much on their own in terms of security solutions. ®

Thomas C Greene is the author of Computer Security for the Home and Small Office, a comprehensive guide to system hardening, malware protection, online anonymity, encryption, and data hygiene for Windows and Linux.

Related stories

Windows XP SP2 features security crater - report
XP SP2 über patch already needs fixing
200 apps clash with XP SP2
WinXP SP2: stop moaning and get downloading