How Windows XP SP2 Secured RPC Against Worms

Windows XP Service Pack 2 (SP2) fundamentally overhauled the Remote Procedure Call (RPC) subsystem by restricting anonymous network access, enforcing stricter interface-level Access Control Lists (ACLs), and integrating default host firewall filtering. Prior to SP2, unauthenticated remote attackers could invoke critical system services over network ports, leading to widespread worm outbreaks like Blaster and Sasser. SP2 eliminated these attack vectors by abandoning the historic "open-by-default" communication model in favor of strict authentication and granular authorization requirements.

The Problem: Pre-SP2 Remote Exposure

Before Service Pack 2, Windows XP registered many core RPC interfaces without adequate authorization checks. Services listening on TCP port 135 (the RPC Endpoint Mapper) and port 445 (Server Message Block) frequently accepted calls from unauthenticated remote users, including null sessions. If an exposed RPC function contained a memory corruption flaw—such as the DCOM interface vulnerability exploited by the Blaster worm (MS03-026)—any system on the local network or internet could execute arbitrary code with SYSTEM privileges without credentials.

Restricting Anonymous RPC Access

To counteract this, SP2 introduced system-wide controls that blocked unauthenticated callers from accessing RPC interfaces:

  • Default Authentication Requirement: SP2 updated the RPC runtime to reject calls from anonymous clients by default.
  • Opt-in Anonymous Access: Developers and legacy system components were required to explicitly register interfaces using the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag if anonymous network communication was truly required. Without this specific flag, the RPC runtime dropped unauthenticated packets before they reached the service implementation.
  • Interface-Level Security Descriptors: SP2 enforced the use of the RpcServerRegisterIf2 and RpcServerRegisterIfEx functions, allowing developers to define an explicit security descriptor for each interface. This meant that the operating system, rather than custom application logic, enforced whether a specific user had the right to invoke the RPC interface.

Computer-Wide DCOM Limits

Because the Distributed Component Object Model (DCOM) relies on RPC, SP2 introduced new computer-wide Access Control Lists for DCOM launch and activation:

  • MachineLaunchRestriction and MachineAccessRestriction: SP2 created explicit machine-level restrictions in the registry. These policies overrode individual application settings and outright denied anonymous users the ability to remotely launch or activate DCOM servers.
  • Reduction of Remote Activation Privileges: Remote activation was limited exclusively to administrators by default, preventing low-privilege network accounts and compromised local accounts from invoking remote objects.

Windows Firewall by Default

Beyond protocol-level changes, SP2 introduced the Windows Firewall (formerly Internet Connection Firewall), which was turned on by default for all network interfaces:

  • Closed Inbound Ports: Inbound traffic to TCP port 135, TCP/UDP port 445, and NetBIOS ports (137–139) was blocked entirely by default.
  • Isolation of the Endpoint Mapper: By preventing inbound connections to port 135, external scanners could no longer query the RPC Endpoint Mapper to discover which dynamic RPC services were active on the machine.

By combining mandatory interface authentication, machine-wide DCOM permission ceilings, and active inbound firewall filtering, Windows XP SP2 effectively closed the unauthenticated network pathways that self-replicating worms relied upon to compromise systems.