Information About Reported Architectural Flaw in Windows
|Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.|
Note: new information on this topic can be found the in the MS02-071 security bulletin.
A recent white paper suggesting that an architectural flaw exists in Windows has generated interest in the press and on security mailing lists. While some of the report's findings are correct, its core assertion that there is an architectural flaw in Windows is inaccurate. The Microsoft Security Response Center has thoroughly investigated the report's claims, and we'd like to provide our customers information about our findings and our planned future steps.
The white paper details a type of attack that the author has termed a "shatter attack." Its central premise is that if a highly privileged service runs in the interactive desktop, it would be possible for the user to make use of its privileges. (The interactive desktop is an architectural construct in Windows, in which all services that interact directly with the user execute). This could enable a user to gain privileges on the system in the most extreme case, giving him or her complete control over the system.
The paper is correct that this situation exists, and it does correctly describe its effect. It's worth noting several important points, though.
The situation only exists if there is a highly privileged service running in the interactive desktop. Microsoft has long recommended that interactive services should have only minimal privileges (or, alternatively, steps should be taken to prevent their privileges from being abused).
The user could only abuse this situation if he or she could log onto the system interactively. While servers and other high-value systems typically are configured to prevent this, the attack could pose a threat to workstations and terminal servers.
The privileges gained by the user would exist only on the local machine. That is, the user would not gain any privileges on the domain.
Where the paper errs is in claiming that this is a flaw in Windows. In reality, the flaw lies in the specific, highly privileged service. By design, all services within the interactive desktop are peers, and can levy requests upon each other. As a result, all services in the interactive desktop effectively have privileges commensurate with the most highly privileged service there. The need to limit the privileges of interactive services is well-documented in a variety of sources, as several independent contributors to security mailing lists pointed out when the report was released. The first Microsoft Knowledge Base article that documents this issue dates back to 1994.
As part of our investigation of the report, Microsoft examined its own services, and found a small number of cases in which Microsoft-developed interactive services do run with inappropriately high privileges. We are developing patches to correct these services, and will release them to users shortly. We also are working to ensure that third-party developers are well-informed on this topic (for instance, we recently published updated articles on the subject in the Microsoft Knowledge Base and in MSDN). Finally, as part of our ongoing commitment keep users information safe, we are investigating additional code changes that we believe will make it more difficult although not impossible to exploit a highly privileged service running in the interactive desktop when it exists.