XP SP2--Dedicated To Security
Microsoft’s next Service Pack for Windows XP is almost totally about improved security. And it shows.
- By Bill Boswell
- June 01, 2004
In the upcoming Windows XP Service Pack 2 release, Microsoft appears
to have taken a cue from the late senator Barry Goldwater: Extremism in
the pursuit of security is no vice.
You’ll immediately know that the security landscape of XP has changed
when you restart following the service pack upgrade and the very first
splash screen says, “Help Protect Your PC,” then prompts you to turn on
automatic updates. The very first thing that happens when you log on is
the launch of a new Security Center applet that notifies you of the status
of critical security underpinnings: Firewall, Antivirus and Automatic
Updates (See Figure 1).
|
Figure 1. Windows XP Service Pack 2’s new
Security Center applet. (Click image to view larger version.) |
If, prior to the service pack installation, you had applications that accepted incoming connection requests, you’ll get security notifications that these incoming requests have been blocked.
Believe me, these are just the initial clues that life in the world of
XP SP2 will be considerably constrained. Forget about the No Worries…Be
Happy friendliness of the old Windows. Getting to know XP SP2 is like
trying to be friends with Andy Sipowicz from NYPD Blue.
The list of security and operational changes in XP SP2 is extensive.
The release notes run on for nearly a hundred pages. In this column, I’ll
briefly discuss the changes, so you can start getting prepared for what’s
in store when you update your fleet of desktops.
Windows Firewall
One of the most significant changes in XP SP2 is the default firewall
placed on the local network interfaces. In deference to its new role,
the firewall has been renamed from Internet Connection Firewall to Windows
Firewall.
Putting a firewall on every desktop inhibits the proliferation of worms
in your private network. Universities and other open environments will
see immediate benefits from this feature, and I think other organizations
will adopt the Windows Firewall once administrators figure out how to
make their mix of applications work behind a firewall. In the meantime,
you can turn it off with a group policy (Figure 3).
The major operational update in the Windows Firewall lies in its control
of connections initiated outside the local machine. Microsoft called these
exceptions. The old ICF allows opening ports for inbound connections such
as Web or FTP or remote desktop. Windows Firewall makes this process much
simpler by allowing the user to select a service or application then opening
the ports requested by that application. You can add services or ports
to the list, as shown in Figure 2.
|
Figure 2. Windows Firewall makes it simple to
specify exceptions to firewall port blocks. (Click image to view larger
version.) |
|
Figure 3. Group policy settings control profile
selection for Windows Firewall on domain member laptops. (Click image
to view larger version.) |
The real news, though, is the ability to restrict inbound connections
based on their origin. You can configure a port or ports to accept connections
only from the local subnet. This significantly reduces the ability to
attack the desktop.
Laptop users fall into a special firewall category, as you might expect. You may want the laptop to have exceptions for remote desktop and NetMeeting in the private network but block all inbound connections on the road. Microsoft calls this a “shielded” configuration.
New group policy settings allow you to define separate profiles for firewall configuration. The Domain Profile defines settings appropriate for operation behind a corporate firewall, with standard exceptions and the ability to define specific ports and applications. The Mobile Profile can define more restrictive settings. The laptop uses Network Location Awareness (NLA) to determine whether to use the Domain or Mobile profile, meaning that once the laptop loses touch with a domain controller, it shifts to the Mobile profile.
The firewall has a boot-time policy that protects the machine until the full firewall can load. This protects the machine from an exploit that tries to sneak in during a vulnerable time between operating system initialization and firewall initialization. This boot-time policy can’t be modified.
Command-line addicts such as I will like the addition of the firewall settings to the “netsh” utility. This permits scripting of the firewall configuration.
If you’re getting ready to test IPv6 in your organization, you’ll like
the way XP SP2 installs IPv6 automatically and configures the firewall
to work with both IPv4 and IPv6. The “netsh” utility can be used to separately
configure the two firewalls.
RPC Restrictions
As we’ve all come to realize over the last few bloody months of worms
and viruses, the Remote Procedure Call (RPC) in Windows is a powerful
tool, whether used for good or nefarious purposes.
Many RPC vulnerabilities leverage the willingness of an RPC service to
accept anonymous connections. XP SP2 demands a secure connection, even
if the application doesn’t require it. You can see the beneficial effect
using the Rpcdump utility in the Windows Server 2003 Resource Kit. Point
Rpcdump at a standard XP desktop and you’ll get a full list of the RPC
services running on the machine. Point Rpcdump at an XP SP2 machine and
you get a brusque “Access Denied.”
Execution Protection
A buffer overflow exploit takes advantage of an unchecked variable or
heap entry to expose malicious executable code in an unauthorized area
of memory. Programmers must diligently do bounds checking in their code
to prevent these exploits. One little mistake can cause havoc.
Microsoft has teamed with Intel and AMD to reduce the vulnerability of Windows to buffer overflows by protecting memory using tags that either allow or deny executables to launch. This No Execute (NX) scheme is currently supported by AMD Athlon and Opteron chips. The newest Intel Prescott-based Pentium 4 chips will also support NX.
With execution protection enabled, the processor will throw an exception when asked to execute code exposed by a buffer overflow. The Performance Options section of the System Properties applet has a new tab called Data Execution Prevention that allows you to disable the NX feature if you need to maintain compatibility with a legacy application (Figure 4). The new Application Compatibility Toolkit has settings to disable DEP for specific applications, though, so try that first.
|
Figure 4. Presuming you’re
running the appropriate hardware, the Data Execution Prevention management
dialog allows you to enable or disable memory execution protection
to fight buffer overflow attacks. (Click image to view larger version.) |
Internet Explorer Restrictions
Many exploits target Internet Explorer, so it’s not surprising that XP
SP2 adds quite a few new security features to Internet Explorer and its
cousins: Outlook Express, Infopath, Microsoft Messenger and MSN Messenger.
You can see a list of feature restrictions by opening the Registry and navigating to HKLM | Software | Microsoft | Internet Explorer | Main. Here you’ll find a new key called FeatureControl that contains nine new feature restrictions, including:
Behaviors. When you visit a Web page that uses Dynamic HTML (DHTML),
the page exhibits certain behaviors as you run your mouse over the elements
or click something. Developers usually package these behaviors in an HTC
file, but IE 5.5 permits them to be compiled in a C++ executable. This
feature, called Binary Behaviors, currently avoids the zone restrictions
(Internet, Intranet, Restricted) assigned to a Web page. XP SP2 sets a
Registry flag that blocks binary behaviors completely within the Restricted
Sites zone.
Disable_MK_Protocol. Windows uses a variety of protocols to locate,
decompress, and open HTML-based help files. The HH.exe help engine in
XP defaults to a protocol called MS-ITS. You can see this protocol in
the shortcuts used to open the various help pages in a CHM file. For example,
here’s a shortcut from one of the new help files for WiFi Protected Access
(WPA):
Older help files (IE 3.0) use a protocol called mk:@MSITStore. This protocol hasn’t been given the same kind of exhaustive security scrutiny as MS-ITS and is blocked by default in XP SP2.
LocalMachine_Lockdown and Zone_Elevation. Each IE Web page gets
a security zone. These zones are templates in the Registry that define
sets of access restrictions. KB article 182569, “Description of Internet
Explorer Security Zones Registry Entries,” lists the security zones and
gives lots of low-level detail about the Registry settings and how they
work. You can’t see it in the Internet Options window, but the local machine
has its own zone that, up until now, has been given virtually unfettered
access to the system, like a college kid whose parents are on vacation.
The vacation’s over with XP SP2. Now, ActiveX controls can’t run in the
local machine zone unless the user gives express permission. Data access
to servers in different DNS domains also requires express user permission.
Binary code isn’t allowed to execute, nor are Java scripts. Internet Explorer
also blocks scripts from elevating the security zone to a less trusted
setting than that assigned to the base URL.
MIME_Handling
and MIME_ Sniffing. When Internet Explorer analyzes the content of
a Web page or downloaded file, it decides how to handle the file based
on the MIME type assignments and an analysis of the content itself. XP
SP2 takes this content analysis to the next level by automatically renaming
a file to match its true content before placing the file in the Internet
cache. It also prevents promoting one MIME type to another (text to HTML,
for example) if the second MIME type has additional functionality.
Object_Caching. A theoretical exploit exists in IE 5.5 based
on functionality in the HTML handler that maintains state in the HTML
rendering engine when you navigate between pages in a Web site, or between
the outer and inner pages of a frame. This speeds up operation and adds
flexibility, but makes it possible to access cached scripting objects
from different pages, opening up the possibility that the cached object
could access information from another Web site or more protected portions
of the same site. XP SP2 blocks access to cached objects when navigating
away from the page that loaded the object.
WEBDoc_PopupManagement. IE now includes a pop-up blocker! Do
I hear you say hooray? In the Internet Properties window, select the Privacy
tab to see the Block Pop-up Windows option (Figure 5). Although this feature
isn’t turned on by default, the first time you encounter a site with a
pop-up, you’ll be prompted to enable pop-up blocking. Once enabled, when
you encounter a site with a pop-up, a notification icon appears in the
status bar and the user also sees a notification in the new Information
Bar (right under the toolbar). You can choose to see one pop-up or all
pop-ups from a site.
|
Figure 5. The new IE pop-up blocking option available
in Internet Properties. (Click image to view larger version.) |
Windows_Restrictions. If a user decides to allow pop-ups, you don’t
want the pop-up to fool the user into performing an exploitable act by
hiding important warnings or by covering a page with an alternate page.
For this reason, the Windows_Restrictions feature constrains the size,
position and format of pop-up windows. Windows Restrictions also mandates
that pop-ups have a status bar and a menu bar. This prevents borderless
pop-ups from hiding important security information that would ordinarily
be displayed in the status bar or notification area.
Microsoft Java Virtual Machine
The current version of IE has one set of controls for Java—High, Medium,
Low Safety and Disable. Unfortunately, if you disable Java, you disable
not only the Microsoft Java Virtual Machine (JVM), you disable all other
JVMs on the machine. The new Java settings in XP SP2 differentiate between
the Microsoft JVM and Java settings in general.
Add-On Management
With ActiveX controls and other IE extensions, it’s fairly simple to get
malicious code onto a machine by convincing a user to load them in the
guise of something enticing. Training users to differentiate between good
controls and those from potentially mischievous sources isn’t easy. Even
if you identify sources of spyware, malware and what-the-heck-is-this-going-to-do-to-my-networkware,
it isn’t easy to block users from downloading the bad ones while permitting
them to download the good ones.
XP SP2 introduces a new feature called Manage Add-ons that helps handle ActiveX controls and other IE extensions. The management interface is exposed at View | Manage Add-ons.
The Manage Add-ons window lists the add-ons currently loaded and their status. You can use this window to disable an add-on if it causes a problem. The window also has an option to show “Add-ons that have been used by Internet Explorer,” giving you a history of what the user’s loaded that could potentially have caused a problem in the past.
The default configuration of XP SP2 blocks ActiveX controls and other add-ons while notifying the user in an Information Bar under the toolbar.
Clicking the Information Bar results in a security warning shown in Figure
6. Unlike the current security warning, the Publisher link in the new
window clearly shows the source of the control and the validity of the
digital signature without including complex certificate information unless
requested.
|
Figure 6. The new Security Warning window is
simpler to understand. (Click image to view larger version.) |
If the user elects not to install the control, the Add-on Manager blocks the control from that point forward. An icon appears in the status bar notifying the user that the control has been blocked and providing a link to allow loading it, if desired.
These status bar and information bar notifications are controlled by a new setting called Notify When Add-ons Disable in the Browsing section of the Advanced tab of Internet Options.
The Security settings in the same window have a new setting called Allow the Installation of ActiveX Controls That Have Invalid Signatures that can be checked to deny loading unsigned controls.
You can whitelist and blacklist controls by making Registry entries under this key: HKCU | Software | Microsoft | Windows | CurrentVersion | Policies | Ext. The entries are keys called AllowList and DenyList. You’ll need to create the keys. To deny a user the ability to load a particular control, create a subkey under DenyList with a name that corresponds to the Class ID (CLSID) of the control. The simplest way to get the CLSID is to load the control on a test machine, put it on the Deny list manually, then look for the corresponding key under HKCU | Software | Microsoft | Windows | CurrentVersion | Settings.
You can distribute the Registry updates manually via logon scripts, use your favorite deployment tool or create a custom ADM template that includes the policy settings.
IE now also has special handling for detecting and analyzing add-on crashes. Rather than simply using Windows Error Reporting to send information about the crash to Microsoft, you’ll first get an Internet Explorer Add-on Crash Detection Window that lists the name of the company that wrote the add-on. You can use this information to disable the add-on in the Manage Add-ons window.
You can use the Manage Add-ons window to update an ActiveX control or
to disable the add-on if it keeps misbehaving.
Download Management
When downloading files in IE, you’re probably familiar with the security
window that asks for your explicit permission to open a file or run an
executable. In XP SP2, you may be surprised to see this same security
window appear when you open a file after saving it to your local drive.
There’s been a fundamental operational change in XP SP2 that was first
discovered by a sharp-eyed Norwegian administrator named Torgeir Bakken.
In XP SP2, when you download a file—any file—from the Internet, the file
gets marked with an NTFS-named data stream called Zone.Marking. This stream
contains the location where the file was downloaded. For example, if you
download the Google Toolbar Installer, the executable would have the following
Zone.Marking stream:
[ZoneTransfer]
ZoneUri=http://toolbar.google.com/data/
en/big/current/GoogleToolbarInstaller.exe
To see the named data stream, use the More command as follows:
More < executablename.exe:zone.="">
Each time you launch an executable (or script) from Explorer that has this named data stream, either on the same machine or from a network share, you’ll get the security warning shown in Figure 7. This warns users that an executable downloaded from the Internet stays potentially dangerous even after it lands on a local drive.
|
Figure 7. A security warning pops up for downloaded
files—even if launched from the local drive. (Click image to
view larger version.) |
To get rid of the warning, you need to remove the named data stream.
The final version of XP SP2 will have a feature for this. You can also
use the Streams utility from Sysinternals, www.sysinternals.com.
By the way, if you download a .zip file then extract the files, each
of the extracted files gets a named stream that points back at the .zip
file. This means you still get the warning.
You Asked for It…
OK, folks, we said we wanted better security on the
Windows desktop and by jingo, here is a big, big package dedicated nearly
100 percent to security. It’s not perfect, but it’s a huge improvement
on many different levels. I hear a lot of moaning and groaning about Microsoft
security, but I don’t see the complainers rushing to deploy Windows products
that incorporate serious, demonstrable security improvements. Here’s our
chance to turn the tide.