Improving Resiliency with Windows XP Service Pack 2
Part 2 of 2
Steve Riley
Product Manager, Security Business & Technology Unit
Microsoft Corporation
Welcome to part two of this series on Windows XP Service Pack 2 (SP2). Last month we reviewed the first of four security scenarios that the firewall helps mitigate: blocking attacks. This month we’ll explore the other three: how to help foil spyware, stop email worms and other malicious code, and reduce buffer overrun exploits.
Foil spyware
It is, alas, still very easy to trick people into installing unknown software or answering "innocent" dialog boxes. Many websites are built with alluring come-ons or deceptive dialogs that look like they were generated by the operating system. Especially notorious are system “tune-up” utilities (that seriously degrade performance), dialogs claiming that you’re missing critical security updates (the installation of which usually adds spyware), and pop-up windows advertising, of all things, software that blocks pop-up windows!
The service pack incorporates a number of changes to Internet Explorer to help reduce this pain. One common avenue of attack is to create windows that don’t look like windows and then entice users to engage in bad behavior. For instance, say a script opens a 1290 × 1054 window on your 1280 × 1024 desktop and centers it. What’s hidden? All the stuff, the "chrome," that makes a window look like a window: title bar, status bar, frame, toolbar, and menu bar. Also missing is the address bar and the security zone. Furthermore, that window may also contain innocent-looking icons like My Computer, My Network Places, and Recycle Bin. Finally, the script might open a dialog that reads "Your network connection has been lost. Please re-enter your ID and password." Now, how many people do you know who might fall for such a trick?
Changes to the windowing engine now prevent such attacks. Windowing restrictions place limits on what scripts can do:
Scripts can’t position or resize windows with title and status bars off-screen; such windows will be moved or resized to fit within the bounds of the screen.
Scripts can’t turn off the status bar.
Scripts can’t conceal the address bar or security zone indicator.
Windows must fit between top and bottom of the parent, overlap the parent horizontally, and move with and appear above the parent.
Now that Microsoft Internet Explorer controls what scripts can do with windows, the browser includes a built-in pop-up manager. The pop-up manager blocks script-initiated windows when the script is running in either the Internet Zone or the Restricted Sites Zone. (Not affected are pop-ups initiated by locally-running code or mouse clicks.) When a pop-up is blocked, you can choose to display it if you want; you can also control whether certain websites or entire domains are exempt from blocking. Any pop-ups you permit are constrained by the new limits described earlier.
If you’ve configured Internet Explorer’s security zone settings to prompt you for ActiveX download, you might have been confused by the dialog box that appears. It’s full of warnings but without much guidance. And, it gave you only one option for controlling more prompts: always trust the publisher. SP2 now displays a warning in the notification bar if a website attempts to install a control. You can click the information bar for more details, including a new option: never trust the publisher. This circumvents an increasingly common attack where a page filled with several ActiveX controls tries to frustrate you into always trusting the publisher—after which malicious code is delivered in the last control. By indicating never to trust the publisher (which is really only for this page, not for all time) then you can thwart this kind of attack.
Add-ons are common ways of extending Internet Explorer functionality—using toolbars, browser extensions, browser helper objects, and ActiveX controls. Some malicious code and spyware installs as Internet Explorer add-ons and often causes strange system behavior and can introduce instability. A new add-on management function allows you to control whether individual add-ons are loaded when Internet Explorer starts. In our evaluation of Internet Explorer crashes, we discovered that most crashes are caused by poorly written add-ons. If an add-on crashes, Internet Explorer displays the add-on management dialog with the particular add-on highlighted so you can disable it.
Stop email worms and other malicious code
Despite all the warnings and dangers of file attachments, they continue to be one of the most troublesome attack vectors for infecting a computer system. And as instant messenger programs become more popular, these too can be used to deliver malicious code. SP2 includes a new set of APIs called the Attachment Execution Service (AES) that both Internet Explorer and Windows Messenger use when users access attached files. While many applications warn users about potentially dangerous files, the warnings are often confusing and lack enough information to help users make appropriate decisions. The service provides a consistent experience regardless of application and directs users to a location where they can learn more information about attachment security. These APIs are public; Microsoft encourages other third-party developers to implement them in future applications.
Other enhancements to Outlook Express also help to thwart malicious code. You can configure Outlook Express to read all email as plain text, which stops malicious code from being delivered in HTML header scripts. You can always decide to render a specific known-safe email in HTML. Outlook Express also allows you to block images and other external content in HTML mail, thus rendering web bugs ineffective. Web bugs are links to tiny 1 × 1 pixel images which, when retrieved by Outlook Express after you open an email, violate your privacy by validating your email address for future spam.
There are many more technical enhancements to Internet Explorer for thwarting malicious code, including:
Local machine zone lockdown
Zone elevation blocks
MIME handing enforcement
Changes to object caching
Changes to binary behaviors
Bind-to-object mitigations
Group policy settings for feature controls and URL actions
Please see the “Changes to Functionality in Microsoft Windows XP Service Pack 2” document for more details.
Reduce buffer overrun exploits
Buffer overruns can be eliminated from all code, but this takes time; attackers will continue to exploit overruns or—worse—deliver purposefully broken code to be exploited later. SP2 includes support for a processor feature called Data Execution Prevention (DEP) that will stop most buffer overruns from harming your computer.
Computer memory holds two kinds of information: data and executable code. Good software engineering limits where executable code can be stored; it’s bad practice to store code in areas of memory typically used for data (like the default heap, various stacks, and memory pools). Nearly all worms and viruses place executable code in these areas and then exploit buffer overruns to make the system execute the bad code.
DEP, also sometimes called "no execute" or "NX," is an operating system feature that relies on processor hardware to mark memory as executable. Processors supporting DEP now include Intel Itanium 64-bit CPUs and AMD K8-architecture Athlon/Operon 32-bit CPUs. When the processor detects that the operating system has been requested to execute code from an area of memory that should contain only data, the processor raises an exception. The operating system then handles the exception.
In 64-bit Windows, all applications are expected to behave with DEP enabled—indeed, there’s no way to disable it. By default all of the memory in the computer is protected; developers need to specifically mark executable pages with special memory calls. The stack, heap, and memory pools are always protected and can’t be used to run code.
In 32-bit Windows, the behavior depends on what’s executing. User-mode applications that attempt to execute code from protected memory are terminated. It’s possible to disable DEP for programs you know aren’t malicious but nevertheless engage in poor software engineering practices. Kernel-mode device drivers that attempt to execute code from the stack cause Windows to halt with a blue screen message. There’s really no way to selectively terminate kernel-mode drivers without destabilizing the operating system; it’s better for an infected computer to halt than to permit it to infect other computers. Our testing shows that there’s nothing here for you to worry about: it’s very atypical for good drivers to exhibit this behavior, but nearly all worms do.
Over time, as software engineering improves and DEP becomes standard in all CPUs, the likelihood of a successful buffer overrun attack will be greatly reduced.
Thanks for reading through my two-part introduction to the security enhancements in Windows XP Service Pack 2. We believe that these changes are necessary to increase the resiliency of Windows XP to make it even better able to withstand the endless onslaught of attacks clogging public (and even some private) networks. Learn more about the service pack.
The service pack has been released to manufacturing and will be available for download very soon.
We welcome your feedback. Please use the "Comments" link at the bottom of this page. Thanks very much.