Introduction

With the release of Windows XP Service Pack 2 (SP2), Microsoft® has tackled head-on customer security concerns, thus making Windows XP a more secure platform, ready to meet today’s business challenge. Microsoft has developed resources, such as this guide and accompanying scripts, to help you understand and deploy Windows XP SP2. Links to additional resources appear throughout this guide.

The benefits of Internet connectivity to organizations have resulted in networks becoming open to hostile actions increasingly beyond the control of an individual. To counter this rising threat, IT administrators must maintain a secure environment in which their computer systems can work. To achieve a suitable level of security, desktop computers running Windows XP need protection against abuse and misuse.

Microsoft has dealt with security issues in the past by providing individual security updates for system components and applications. While this methodology is successful, it requires continuous monitoring and regular deployment of updates. System-wide security features, on the other hand, protect the computer as a whole, and minimize risk for each individual component. Windows XP SP2 implements system-wide security features that provide a protection layer above existing security update technologies. Windows XP SP2 also implements more restrictive default configurations for security and communication-related features.

Viruses and hackers are limited to the same communication protocols and functionality as network-based applications, so increasing security in the network environment can result in legitimate applications or features not operating as expected. Finding the correct balance between functionality levels and adequate security is a continuous administrative challenge. Microsoft has always provided feature-rich software, but the need to secure the operating environment has become paramount. The security features in Windows XP SP2 can make Windows XP a more secure environment. However, applications that were not designed to meet these higher security requirements may experience some compatibility issues.

On This Page

Scope
Audience
Security Enhancements
Summary

Scope

This Application Compatibility Testing and Mitigation Guide for Windows XP Service Pack 2 provides information on how to ensure that applications operate with Windows XP SP2. It includes process roadmaps and guidance on how to identify and mitigate compatibility issues and how to deploy mitigation fixes. This guide describes the security technologies implemented by Windows XP SP2 and provides guidance for mitigating application compatibility issues that were identified by performing extensive testing of Microsoft and non-Microsoft applications. This guide also includes details about changes and enhancements to the following features in Windows XP:

• Internet Explorer. Windows XP SP2 implements many important changes to the features and functionality of Internet Explorer, including download controls, attachment and Authenticode® enhancements, Add-on Management, zone elevation blocks, and pop-up management.

• Windows Firewall. This is an updated version of the Internet Connection Firewall (ICF). The purpose of the Windows Firewall is to block unsolicited attempts to communicate with a computer running Windows XP SP2. The Windows Firewall does not prevent communication originating from the computer.

• Data Execution Prevention (DEP). This is a feature that can prevent unwanted, unexpected, or malicious code execution on a computer running Windows XP SP2.

• Distributed Component Object Model/Remote Procedure Calls (DCOM/RPCs). Windows XP SP2 includes the option to make Remote Procedure Calls (RPCs) and Distributed Component Object Model (DCOM) network communications more secure. The enhancement to DCOM security gives the option to implement system-wide security requirements, and RPC connections can be configured to require authentication and not accept an anonymous context. This, with some exceptions, is the default with Windows XP SP2.

• Attachment Management. E-mail is a major entry point for attacks on organizational networks, and the distribution of viruses using e-mail attachments is increasingly common. Windows XP SP2 introduces the Attachment Manager with enhanced protection against potentially unsafe file attachments.

Figure 1.1 identifies the key points of this guide and how they relate to each other.

Figure 1.1 Flowchart showing key points for the Application Compatibility Testing and Mitigation Guide for Windows XP Service Pack 2

The process of checking for application compatibility includes the following tasks:

1. Understand the security technologies, the reasons for implementation, the methods of implementation, and the likely impact.

2. Test applications for compatibility with the security technologies.

3. Reconfigure, upgrade, or redevelop any incompatible applications to work with the technologies.

4. Mitigate application compatibility issues, if required, with short term fixes that make the security configuration less restrictive.

If it is necessary to apply short term fixes, repeat this process until all applications are compatible with the new security technologies.

Audience

The information contained in this guide is targeted at IT professionals and administrators in roles ranging from support to application testing, security configuration, and network administration. This guide does not assume a particular size or complexity of network, and covers peer-to-peer, domain, and Active Directory® environments. The security information is relevant even for networks that do not have access to the Internet.

Security Enhancements

Windows XP SP2 is more than a roll-up of security updates – it introduces a number of new features together with enhancements for existing technologies. These changes cover:

• Internet Explorer

• Windows Firewall

• DEP

• DCOM/RPCs

• Attachment Manager

• Miscellaneous enhancements

Internet Explorer

Internet Explorer is one of the most frequently used system components, and has grown beyond a simple Web browser to a front end for databases and intranet applications. Internet Explorer operates in an environment that often requires automation. Downloading applications, files, and ActiveX® controls, opening additional Web pages, and installing add-on features are just a few of the automated functions that support dynamic and user friendly Web pages and Web applications. Although these automated features are extremely useful in providing a rich user experience, they can also cause harm if used maliciously.

To help prevent attacks, Windows XP SP2 uses a structured security model that allows an administrator to configure layered security using security zones. Configuration of security features can be different for each zone. Therefore, when designing an overall security policy, developers must be aware of what is allowed in each zone, and create applications that conform to the security model for the zone. Windows XP SP2 also implements a more restrictive executing environment, which requires application developers to be conscious of security when writing applications for a Web-based environment.

New or enhanced features in Internet Explorer include the following:

• Feature control

• UrlAction security

• Binary behaviors

• Local machine lockdown

• Multipurpose Internet Mail Extensions (MIME) handling

• Object caching protection

• Windows restrictions

• Zone elevation blocks

• Information bar

• Pop-up management

• Add-on management

This section discusses each of these features in turn.

Feature Control

Windows XP SP2 includes registry settings permitting specific processes to opt in or out of relevant security features. Once Feature Control is enabled, configuration of security features can be separate for each security zone. You can configure Feature Control settings using Active Directory Group Policy, through the Security tab of Internet Options in Control Panel or by editing the registry.

To view additional information regarding this technology in this guide, click the following links:

Application Compatibility Testing for Feature Control

Application Compatibility Issue Mitigation for Feature Control

UrlAction Security

UrlActions are automated features that are incorporated into Web Applications to provide additional functionality. UrlAction settings are configurable on the Security tab of the Internet Options user interface (UI). Windows XP SP2 introduces the ability for an administrator to use Group Policy for the configuration of these settings, which increases flexibility as compared to using the Internet Explorer Administration Kit (IEAK) of previous versions.

Some of the UrlAction settings are invalid until the corresponding Feature Control is enabled. A number of the features covered in this guide are configured using Feature Control and UrlAction security.

To view additional information regarding this technology in this guide, click the following links:

Application Compatibility Testing for UrlActions

Application Compatibility Issue Mitigation for UrlActions

Binary Behaviors

Binary behaviors allow Internet Explorer to use a specific Hypertext Markup Language (HTML) element. For example, Microsoft Office uses binary behaviors to create the same look and feel when it saves application-specific files, such as a spreadsheet with a graph in it, as a Web page.

Previous versions of Internet Explorer allowed binary behaviors, which can potentially be harmful even when running in the Restricted Sites zone. With Windows XP SP2, an administrator can enable or disable binary behaviors on a zone-by-zone basis. Binary behaviors are disabled by default in the Restricted Sites zone.

To view additional information regarding this technology in this guide, click the following links:

Application Compatibility Testing for Binary Behaviors

Application Compatibility Issue Mitigation for Binary Behaviors

Local Machine Lockdown

When Internet Explorer opens a Web page, it places restrictions on the capabilities of the page dependent on the security zone that the page came from, for example, the Internet zone or the Local Intranet zone. A page from the Internet zone is more restricted than a page from a local intranet. Although the Internet Options UI does not show the option, Internet Explorer also uses Local zone. Previously, content held locally was assumed to be secure and had no zone-based security applied to it. Content in the Local zone also had fewer restrictions, which resulted in attackers attempting to use the Local zone to gain elevated privileges and compromise the computer. Windows XP SP2 applies greater security to the Local zone by default and provides the administrator the ability to apply Local Zone Lockdown to make this zone even more restrictive.

To view additional information regarding this technology in this guide, click the following links:

Application Compatibility Testing for Local Machine Lockdown

Application Compatibility Issue Mitigation for Local Machine Lockdown

MIME Handling

Multipurpose Internet Mail Extensions (MIME) provide a standard for identifying file types and file handlers. If Internet Explorer tries to download and execute a file from a Web server, it also receives a MIME type for the file that identifies the file type and the default handler of the file. Internet Explorer uses this information to identify which application to use to run the file. Previously, it was possible to use Internet Explorer to download a file and save it to disk using MIME information. When the file was executed at a later date, a different handler could be used. This arrangement allowed an attacker to identify an executable file as text (thereby misidentifying it as safe) when the file was being downloaded. When the file was run at a later date, the MIME information was not used and the file executed, either in an application or in the Windows shell, without prompting the user.

Windows XP SP2 strengthens the use of MIME as a method for identifying file types. With Windows XP SP2, Internet Explorer uses the following information to decide how to handle the file:

• File extension and ProgID of registered handler

• MIME type and the ProgID of the registered handler

• Content-Disposition from the HTTP header

• MIME sniff

If the MIME type does not match the file extension, Internet Explorer attempts to rename the file to match the content type. If this cannot be done, Internet Explorer will not execute the file.

MIME sniffing allows Internet Explorer to recognize the bit signature of a file, potentially identifying the file type. If a Web server does not include the correct content-type information, an HTML file may be viewed as plain text and no active content will be loaded.

To view additional information regarding this technology in this guide, click the following links:

Application Compatibility Testing for MIME Handling

Application Compatibility Issue Mitigation for MIME Handling

Object Caching Protection

Windows XP SP2 prevents a cached object from being available if a user navigates to another domain (as specified by a fully qualified domain name), or if the context changes due to navigation within a domain. This restriction prevents a cached object from providing access to the contents of a Web page from another domain. Therefore, an attacker cannot use a script to check for events in another Internet Explorer frame or window, such as, checking for credit card numbers as they are being entered.

To view additional information regarding this technology in this guide, click the following links:

Application Compatibility Testing for Object Caching

Application Compatibility Issue Mitigation for Object Caching

Window Restrictions

Windows XP SP2 allows Internet Explorer to restrict where scripts can place newly opened windows and also prevents hiding of the title bar, status bar, or address bar. This restriction prevents an attacker from executing a script that opens a window off-screen and hides malicious content or activity, or places a small window over a dialog box to change its meaning.

To view additional information regarding this technology in this guide, click the following links:

Application Compatibility Testing for Window Restrictions

Application Compatibility Issue Mitigation for Window Restrictions

Zone Elevation Blocks

Windows XP SP2 blocks Web pages from navigating to a less restrictive security zone. Zone Elevation Blocks prevent the overall security context for any link on a page from being higher than the security context of the root URL. This approach prevents attackers from scripting page navigations into less restrictive zones and then executing malicious code.

To view additional information regarding this technology in this guide, click the following links:

Application Compatibility Testing for Zone Elevation Blocks

Application Compatibility Issue Mitigation for Zone Elevation Blocks

Information Bar

Windows XP SP2 replaces many of the pop-up dialog boxes, which the user sees currently, with the Information Bar. This Information Bar shows a short text message relating to the event, and appears under the Internet Explorer toolbars and above the Web page. Clicking the Information Bar shows additional information relevant to the event. If more than one event is blocked, the text is more generic with the detail of the events appearing in a list. The Information Bar shows a range of events, including:

• Prompts to install add-ons

• Notification of blocked pop-up windows

• Prompts to carry out automatic downloads

• Notification of ActiveX control prompts that have been blocked

To view additional information regarding this technology in this guide, click the following links:

Application Compatibility Testing for Information Bar

Application Compatibility Issue Mitigation for Information Bar 

Pop-up Management

Windows XP SP2 enables pop-up blocking by default. If a Web page attempts to automatically create another Internet Explorer window, the new window is suppressed and a message appears in the Information Bar. The user can enable the pop-up window by clicking the Information Bar if required. This feature does not apply to windows that open because the user clicked on a link or to pop-up windows within the intranet zone.

To view additional information regarding this technology in this guide, click the following links:

Application Compatibility Testing for Pop-up Management

Application Compatibility Issue Mitigation for Pop-up Management 

Add-on Management

Internet Explorer add-ons are programs that add functionality to the browser. Add-on installation occurs as a download from a Web page, as an application installation, or as part of the operating system, often without the user being aware of the add-on functionality, or even of the existence of the program.

This presents a potential security risk. Windows XP SP2 allows the tracking of installed add-ons through a list, and an administrator can disable add-ons if necessary through the Add-on Manager interface.

To view additional information regarding this technology in this guide, click the following links:

Application Compatibility Testing for Add-on Management

Application Compatibility Issue Mitigation for Add-on Management

Windows Firewall

Windows Firewall is a software firewall that provides stateful inspection and filtering of incoming network communication. An administrator must open a Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) port to allow inbound communication to take place. After installation of Windows XP SP2, Windows Firewall is switched on by default.

If non-Microsoft firewall is present, Windows Firewall is still enabled by default. However, you may experience performance degradation. An administrator may chose to disable the Windows Firewall.

Enabling Ports

An administrator can allow inbound communication through the firewall by specifying the relevant port, or by placing an application executable in an exception list. A specifically opened port remains open all the time, whereas an executable placed in the exception list opens any ports that the application requires only for as long as the application is running.

It is also possible to limit access to a communications port to the local subnet. In a workgroup environment, this happens by default when enabling file and printer sharing. Therefore, ports UDP 137 and 138, TCP 139 and 445, and the Universal Plug and Play (UPnP) service on UDP 1900 and TCP 2869 can only be accessed by computers on the local subnet.

It is possible to configure Windows Firewall to allow no exceptions. This places the Windows XP system into a client-only mode and prevents any incoming communication.

Multicast and Broadcast Support

When using multicast and broadcast-based protocols and services, the computer may receive communication responses from unknown hosts. To prevent Windows Firewall from filtering this traffic, the outgoing port used by the broadcast or multicast stays open for three seconds to receive responses from any system.

Boot-Time Policy

To prevent malicious attacks while the computer boots, Windows Firewall implements a static boot-time policy. This policy allows the computer to perform basic network tasks such as Domain Name System (DNS) host resolution, Dynamic Host Configuration Protocol (DHCP) requests, and to communicate with a domain controller. There are no configuration options for the boot-time policy, but if the Windows Firewall or the Internet Connection Sharing (ICS) service is disabled, or set to manual, the policy is not applied.

Run-Time Policy

Windows Firewall takes effect when the Windows Firewall or the Internet Connection Sharing service starts, at which time the run-time policy is applied. An administrator in an Active Directory environment can then configure two run-time policies, called Domain Policy and Standard Policy, which allow different configurations for mobile computers when disconnected from the domain.

Windows Firewall allows the configuration of a Global Policy, as well as policies for individual network interfaces. The Global Policy configuration automatically applies to any new connection in the Network Connections interface, including non-Microsoft dialers.

To view additional information regarding Windows Firewall in this guide, click the following links:

Application Compatibility Testing for Windows Firewall

Application Compatibility Issue Mitigation for Firewall

Data Execution Prevention

Data Execution Prevention (DEP) is a set of hardware and software technologies that perform additional checks on memory to help protect against malicious code exploits. In Windows XP Service Pack 2, DEP is enforced by both hardware and software.

Hardware-enforced DEP

Hardware-enforced DEP marks all areas of memory as non-executable unless the area explicitly contains executable code. This feature of Windows XP SP2 relies on processor hardware support to mark the memory locations with an attribute that indicates that code should not be executed from that memory location. DEP functions on a per-virtual memory page basis, usually changing a bit in the page table entry (PTE) to mark the memory page.

The actual hardware implementation of DEP and marking of the virtual memory page varies by processor architecture. However, processors that support hardware-enforced DEP are capable of raising an exception when code is executed from a page marked with the appropriate attribute set.

Both Advanced Micro Devices™ (AMD) and Intel® Corporation have defined and shipped Windows-compatible architectures that are compatible with DEP.

Beginning with Windows XP SP2, the 32-bit version of Windows utilizes the no-execute page-protection (NX) processor feature as defined by AMD or the Execute Disable bit feature as defined by Intel. To use these processor features, the processor must be running in Physical Address Extension (PAE) mode.

Software-enforced DEP

An additional set of DEP security checks have been added to Windows XP SP2. These checks, known as software-enforced DEP, are designed to mitigate exploits of exception handling mechanisms in Windows. Software-enforced DEP runs on any processor that is capable of running Windows XP SP2. By default, software-enforced DEP only protects limited system binaries, regardless of the hardware-enforced DEP capabilities of the processor.

Additional DEP Information

By default, DEP only protects system applications and services. However, applications that extend Windows functionality may encounter problems with DEP. Applications may also encounter problems with DEP if the system DEP configuration has changed from the defaults.

If you believe you are experiencing problems with DEP, it is possible to apply a compatibility fix named “DisableNX” using the Windows Application Compatibility Toolkit (ACT).

For more information about Windows Application Compatibility, see the Microsoft Web site at

https://www.microsoft.com/windows/appcompatibility/default.mspx 

To view additional information regarding both hardware and software-enforced DEP in this guide, click the following links:

Application Compatibility Testing for DEP

Application Compatibility Issue Mitigation for DEP

Distributed Component Object Model and Remote Procedure Calls

Changes to DCOM and RPC have significantly enhanced the security of network communications and remotely executing applications.

DCOM

The Microsoft Component Object Model (COM) is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. DCOM is an evolution of COM, which allows the logical distribution of applications across locations. Windows XP SP2 allows an administrator to configure system-wide security settings for DCOM, which enforces a specific minimum level of security that is applied to all COM applications. Configurations of these security settings takes place on the server component, and are relevant only if your Windows XP system is serving the application.

Figure 1.2 shows the new DCOM architecture.

Figure 1.2 DCOM components in Windows XP SP2, showing client and server components

For earlier versions of Windows, permissions on a DCOM application were Launch and Access. For a request to be made to the COM server, COM on the client makes a request to the Remote Procedure Call Session Service (RPCSS) to communicate with the remote system. RPCSS communicates with RPCSS on the remote system, which forwards the request to the COM server. RPCSS on the remote system then launches the COM server if it is not already running, for which the user requires Launch permissions. To access a running COM server, the user needs Access permissions. To obtain an initial pointer to a COM server, the user also needs Activate permissions. However, before Windows XP SP2, this was not a separately configurable permission. There was also no permission differentiation between launching and accessing COM components locally or remotely.

Windows XP SP2 augments these application-specific permissions by adding Activate as a separate permission, and also by differentiating between accessing the COM server locally or remotely. It also adds a new layer of system-wide security. An administrator can configure Launch, Access, and Activate permissions, both local and remote, for the system as a whole. This is a separate access control list (ACL) and does not change the application-specific ACL. To gain access to the COM server, the user must have correct permissions in both ACLs.

By default, this security model prevents COM applications from permitting unauthenticated remote access to the system, which makes the system more resistant to attack.

To view additional information regarding this technology in this guide, click the following links:

Application Compatibility Testing for DCOM/RPC

Application Compatibility Issue Mitigation for DCOM/RPC

Remote Procedure Calls

Applications and services use Remote Procedure Calls (RPCs) for remote communication. Windows XP SP2 allows an administrator to modify the behavior of all RPC interfaces to require security.

Note: The named pipes protocol cannot be restricted in this way due to backward compatibility issues.

The RestrictRemoteClients registry key forces RPC to perform additional security checks for all interfaces and can have one of the following three values:

• RPC_RESTRICT_REMOTE_CLIENT_NONE (0). This causes the system to bypass the new RPC interface restriction. It is entirely the responsibility of the server application to impose appropriate RPC restrictions. This setting is equivalent to the behavior in previous versions of Windows.

• RPC_RESTRICT_REMOTE_CLIENT_DEFAULT (1). This restricts access to all RPC interfaces. It is the default value in Windows XP SP2. All remote anonymous calls are rejected by the RPC runtime. If an interface registers a security callback and provides the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag, this restriction does not apply to that interface. If the key does not exist (default), the system assumes this value for the key.

• RPC_RESTRICT_REMOTE_CLIENT_HIGH (2). This is the same as the RPC_RESTRICT_REMOTE_CLIENT_DEFAULT value, except that the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag no longer exempts an interface. With this value, a system cannot receive any anonymous remote calls using RPC. Applications that use DCOM might not work correctly if this value is set.

This new security model allows an administrator to limit the system attack surface for the RPC protocol.

To view additional information regarding this technology in this guide, click the following links:

Application Compatibility Testing for DCOM/RPC

Application Compatibility Issue Mitigation for DCOM/RPC

Attachment Execution Service

Windows XP SP2 implements a new application programming interface (API) called the Attachment Manager Execution Service (AES). New applications developed to use this API, including Outlook® Express, Windows Messenger, and Internet Explorer, use AES to present additional information relating to attachments and downloads to the user. With AES, the application manages the downloading of attachments and can require signatures for executable files. AES maintains the same security for attachments saved to the hard disk, as these attachments are marked and treated as a downloaded file.

To view additional information regarding this technology in this guide, click the following links:

Application Compatibility Testing for Attachment Execution Service

Application Compatibility Issue Mitigation for Attachment Execution Service

Miscellaneous Compatibility Issues

Deploying Windows XP SP2 could possibly result in compatibility issues in other areas as well. These issues may be varied in cause and display no specific symptoms. Some of these issues require changes to applications, - either additional development work or an upgrade of the software. The following examples of issues are fixable without development work:

• Microsoft .NET Framework languages

• Rich Text Format (RTF) converters

Microsoft .NET Framework Languages

Windows XP SP2 adds additional languages to Windows XP, such as Welsh. Version 1.0 and 1.1 of the Microsoft .NET Framework do not support these new languages and so applications written with these versions cannot use the new languages.

If you experience this problem, you should update the affected systems to the latest version of the Microsoft .NET Framework.

For more information about NET Framework 1.0 SP3 and 1.1 SP1, see the Microsoft Web site at

https://msdn.microsoft.com/netframework/downloads/updates/sptechpreview/default.aspx 

Rich Text Format Converters

Windows XP SP2 disables the RTF converters in Windows XP. The function of these converters was to convert older Word 95 file types to current RTF formats, allowing viewing in WordPad or Notepad. Without these converters, the document shows unrecognized formatting information as garbled characters together with the text.

If you experience this problem, you can edit the registry and add the following value to enable the converters; the key may not already exist.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
\CurrentVersion\Applets\Wordpad
\EnableLegacyConverters=dword:00000001

These converters were removed to reduce the attack surface; re-enabling them reintroduces potential security issues.

Summary

Windows XP SP2 includes changes that significantly enhance the security of computers running Windows XP. These enhancements need to be considered for a successful deployment. The next chapter covers procedures for checking application compatibility.

For more information about Changes to Functionality in Microsoft Windows XP Service Pack 2, see the Microsoft Web site at

https://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2chngs.mspx