Windows Server Reference Guide

Issues Regarding Service Pack 2

Last updated Oct 1, 2004.

In many respects, Windows XP Service Pack 2 is not really a patch as much as a replacement for the Windows client operating system. The principal purpose for this release was to address architectural issues regarding system security. Most notable among these issues is the manner in which networked software components contact each other, in order to share data and trigger each other's functionality. In the original Component Object Model upon which all of Windows' networked software architecture is based, each component basically trusted each other component, to the extent that the other component could respond to signals, identify itself, and fulfill requests for data or pointers to data, without having to go through any rigorous process of authentication.

With modern networked process communications, the fact that a component responds to any signal or request, at all, is a potential security breach. Microsoft knew it would have to address this issue head-on eventually, and knew it would face some flak whenever it did so. Changing the way network component software interacts ends up changing the way all component software interacts to some extent, even for users who aren't on a network, or who are served in small networks by Windows XP. But also, the applications most likely to be affected by this architectural shift are enterprise-wide custom applications, written for pre-existent runtime platforms. In these circumstances, the authors of the applications are not the authors of the inter-application communication—they don't even really need to know what kinds of communication take place over a system, nor why. It's up to the manufacturers of the platform (e.g., PeopleSoft, Oracle, SAP...Microsoft) to revise the way their underlying components contact one another, to make the old communication fit the new model mandated by Microsoft.

It is here where this critical Windows XP issue becomes a Windows Server 2003 issue.

No More "Hi, It's Just Me"

The most egregious violator of the protocols of interprocess communication (IPC) security has absolutely been the authors of those applications themselves. When Microsoft developed the Distributed Component Object Model to enable COM-style IPC over a network, it created a protocol for components to authenticate themselves. This way, a process running on a client XP system can identify itself as a specific process before it requests specific data. The server component in this operation could validate the client's authentication data against its own table, and recognize the client process as one of its own. Such authentication would be necessary, for instance, when a remote insurance adjustor's client requests policy terms changes be made to the home office's database.

This kind of authentication seemed to make sense within the realm of legitimate applications development, which has historically been insulated from both the mindset and the culture of the malicious user. As a result, DCOM's designers could not anticipate two of their own principles being exploited to the extent that they could be characterized as flaws. One is the fact that every component is likely to identify itself as, in a very real sense, me, as though it were the only instance of itself within the whole network, whereas there could literally be hundreds of little mes, all of them called something like "UpdatePolicySpecs," and all of them being equally legitimate and worthy of authentication. This would be true regardless of each of these components' location, point of installation, or the identity of its user.

The second inevitable flaw comes from the notion that the security "interface" is generally the part of any application that is developed last. Therefore, the IPC process is generally engineered to be able to bypass authentication protocols until the real functionality of the application is completed...at which time, development work usually just begins on retrofitting the entire process for security. Bypassing authentication, almost by definition, is the act of switching something off. And when such a switch is built into the system by design, it immediately becomes the central target for exploitation.

The fundamental approach to facilitating IPC in DCOM cannot change without breaking every single application that uses it. So in XP Service Pack 2, Microsoft instead implements a Draconian approach to the bypass concept: Instead of remodeling it, it eliminates it altogether. No longer can a component identify itself as a "null acknowledged" object, or NACK, so that the server-side process can receive that NACK, and grant a blind pass to the component in a "what-the-heck" fashion. Microsoft could accomplish this without altering WS2K3 by simply having XP SP2's version of DCOM filter out all NACK authentications. A client app can send a NACK, but it never goes out, so the server app never receives one. It becomes incumbent, then, on the server app to stop expecting a NACK as a standard authentication signal—a clear indication that process-level security was never implemented in the first place. This is where enterprise-wide applications can break.

Higher-Level Authentication

Under XP2, not only must DCOM components fully authenticate themselves in terms of identity, but also in terms of location and user. This means that components are treated in some ways as users themselves in a very real sense. If you think about it, human users never directly interact with a DCOM component anyway; instead, they use applications and environments that perform that interaction in the background using other components. So in every kind of IPC, the human user (when there is one) and the process facilitating this "use" (and there always is one of those) become equally important.

As a result, only IPC at the local level (for instance, between Microsoft Word and its own spell checker) and during fully authenticated sessions between client and server (where the human user's SID has been exchanged with the server in order for the session to begin) is allowed under the new DCOM system. DCOM therefore cannot take place under an anonymous session. This can break some enterprise applications as well, because some (ill-advisedly) use non-authenticated "sessions on the side" to bypass standard protocols—especially "system sessions" where a client is supposedly cleared automatically because it can identify itself as Windows.

How do you, as a WS2K3 administrator, handle these issues? First, consider disabling automatic updates to your client systems, if you have not already done so, in order to halt your users from updating to XP SP2 before you're ready for them to do so. Next, set up a new pilot XP SP2 under a new, temporary account, where you can test enterprise applications before your own users do. If a break does happen, it will happen in front of you.

References

• "Windows XP Service Pack 2 Overview." White paper available from microsoft.com.

• "Analysis of Windows XP Service Pack 2." Article from Steve Friedl's Unixwiz.net.

• "Windows XP Service Pack 2 with Advanced Technologies Review." Article from Paul Thurott's SuperSite for Windows.