Countdown to XP SP2: Forced Protection

Windows XP Service Pack 2 (SP2) is scheduled for release within the next few weeks. Ever since Microsoft first pushed back the XP SP2 release date from December 2003 to April 2004, I've been going through a love/dislike relationship with the upcoming service pack.

When Microsoft delayed the service pack's release date, I was troubled. Considering that XP first shipped in October 2001, the delay meant that XP users would be getting one service pack every 15 months. Whatever happened to “We’ll get out two service packs per year?” Yes, XP’s pretty reliable, but it still suffers from a number of known networking problems, not the least of which is a nagging Server Message Block (SMB) signing error brought on by the last service pack. True, you don't need to wait for SP2 to get patches for many XP problems, but if those patches aren't security oriented, you have to call Microsoft Product Support Services (PSS) to ask for the patches. And according to the Microsoft articles that refer to those patches, you run the risk of being charged $245 for the call if the person on the other end of the line decides you don’t truly need the patch. Like many of you, I’ve been waiting for SP2 so that I can get all those fixes in one guaranteed-to-be-free download.

But my larger concern was the apparent reason for the 4-month delay: Microsoft's determination to “autoharden” XP. The W32.Blaster worm was a huge embarrassment to Microsoft security folks, who (not unreasonably) asserted that W32.Blaster wouldn't have been such a problem if people had immediately installed the patch that protected against the remote procedure call (RPC) vulnerabilities that W32.Blaster later exploited. Still, the public and press demanded to know what more Microsoft would do to keep a Net-crashing worm like W32.Blaster from wreaking havoc again.

Microsoft’s answer might have gone something like this: “Look, sorry about this RPC bug and yes, it was a big one, but there's no way to create completely bug-free code, so every Windows user really needs to go regularly to Windows Update for free patches.” That’s a fact—people using computers attached to the Internet have a basic responsibility to keep their systems patched. But instead, Microsoft’s answer ran along the lines of “Um, well, if port 135 had been blocked then you wouldn't have gotten this worm, so we’ll—yeah, that’s it!—we’ll block it FOR you, and all the other ports as well, by having SP2 automatically turn on Internet Connection Firewall (ICF) when you install SP2!”

I was frustrated. Turning on ICF completely blocks an XP machine from responding to requests of any kind. Want to ping your XP system from another machine to see if the XP system’s TCP/IP stack is up? ICF discards the incoming ping request, so you’ll never get a response. Want to use the Microsoft Management Console (MMC) Manage Computer snap-in to connect remotely to your XP system so that you can remotely administer it? ICF blocks your request. Want to use the NET USE command to copy a few files from your XP system’s C: drive? ICF blocks that request, too. ICF also stops any attempts to use Remote Desktop, to help someone by using Remote Assistance, or to use any remote control tool at all.

Now, let me be clear: If your XP box is the only computer that you own, and if you don't run a home network but attach your XP box directly to the Internet, then ICF is a great idea. But I worried that installing SP2 on XP boxes that function as workstations inside a corporate intranet—which is probably sitting behind a firewall anyway—would be an instant nightmare. And I especially worried about the home user who sets up an intranet with a few machines and uses an appliance Network Address Translation (NAT) router to attach to the Internet. At first glance, the solution that Microsoft seems ready to promote with XP SP2—“We’ll just turn off networking and hope that if you’re smart enough to turn it back on, you’re also smart enough to stay patched”—seemed an awful lot like an automaker that discovers that its cars explode when driven faster than 65 miles per hour and so installs governors on the vehicles to prevent the cars from going over that speed.

Sure, you can easily turn ICF off or, even better, leave ICF on and open only the ports you need. (If you’re wondering exactly which ports those are, Microsoft has posted "Port Requirements for Microsoft Windows Server System," a spreadsheet that you can download) But who wants to go through all that? I'd heard conflicting reports as to whether Microsoft would provide new Group Policy settings to simplify the process of reopening the ports you need for Microsoft networking, but in any case, I thought, such settings won't be much help for anyone running XP as part of an NT-based domain or small workgroup.

As it turns out, some of my concerns about XP SP2's ICF implementation were unfounded. Dealing with SP2 on XP systems that sit behind a firewall inside a corporate intranet will be troublesome, but not as troublesome as I imagined. I'll explain why in my next installment.