Microsoft Security Bulletin MS02-071 Print
Flaw in Windows WM_TIMER Message Handling Could Enable Privilege Elevation (328310) Originally posted: December 11, 2002
Summary Who should read this bulletin: Customers using Microsoft® Windows® NT 4.0, Windows 2000, and Windows XP.
Impact of vulnerability: Privilege elevation
Maximum Severity Rating: Important
Recommendation: Customers should install the patch at the earliest opportunity.
Microsoft Windows NT 4.0 Microsoft Windows NT 4.0, Terminal Server Edition Microsoft Windows 2000 Microsoft Windows XP End User Bulletin: An end user version of this bulletin is available at: http://www.microsoft.com/security/security_bulletins/ms02-071.asp.
Technical details Technical description:
Windows messages provide a way for interactive processes to react to user events (e.g., keystrokes or mouse movements) and communicate with other interactive processes. One such message, WM_TIMER, is sent at the expiration of a timer, and can be used to cause a process to execute a timer callback function. A security vulnerability results because it's possible for one process in the interactive desktop to use a WM_TIMER message to cause another process to execute a callback function at the address of its choice, even if the second process did not set a timer. If that second process had higher privileges than the first, this would provide the first process with a way of exercising them.
By default, several of the processes running in the interactive desktop do so with LocalSystem privileges. As a result, an attacker who had the ability to log onto a system interactively could potentially run a program that would levy a WM_TIMER request upon such a process, causing it to take any action the attacker specified. This would give the attacker complete control over the system.
In addition to addressing this vulnerability, the patch also makes changes to several processes that run on the interactive desktop with high privileges. Although none of these would, in the absence of the TM_TIMER vulnerability, enable an attacker to gain privileges on the system, we have included them in the patch to make the services more robust.
An attacker would need valid logon credentials to exploit the vulnerability. It could not be exploited remotely. Properly secured servers would be at little risk from this vulnerability. Standard best practices recommend only allowing trusted administrators to log onto such systems interactively; without such privileges, an attacker could not exploit the vulnerability. Severity Rating: Windows NT 4.0 Important Windows NT 4.0, Terminal Server Edition Important Windows 2000 Important Windows XP Important The above assessment is based on the types of systems affected by the vulnerability, their typical deployment patterns, and the effect that exploiting the vulnerability would have on them.
Vulnerability identifier: CAN-2002-1230
Tested Versions: Microsoft tested Windows NT 4.0, Windows NT 4.0, Terminal Server Edition, Windows 2000, and Windows XP to assess whether they are affected by these vulnerabilities. Previous versions are no longer supported, and may or may not be affected by these vulnerabilities.
Frequently asked questions What’s the scope of the vulnerability?
This is a privilege elevation vulnerability. An attacker who successfully exploited this vulnerability could gain unwarranted privileges on a system. In this case, the attacker could gain full administrative privileges, thereby gaining the ability to take any desired action on the machine, such as adding, deleting, or modifying data on the system, creating or deleting user accounts, and adding accounts to the local administrators group.
The vulnerability could only be exploited by an attacker who had credentials to log onto the computer interactively. Best practices suggest that unprivileged users not be allowed to interactively log onto business-critical servers; if this guidance has been followed, such servers would not be at risk from this vulnerability. Instead, the systems primarily at risk would be workstations and terminal servers.
What causes the vulnerability?
The vulnerability results because it is possible for an unprivileged user to cause code to be executed by a highly privileged process on the interactive desktop using the Windows WM_TIMER message.
What do you mean by a "desktop"?
Normally, when we refer to a "desktop", we mean the Windows desktop that you see on your screen during a Windows session. However, in the Windows security architecture, the term desktop actually has a different meaning. Desktops are used to encapsulate processes in Windows in order to ensure that a process is properly restricted to only authorized activities. It's easier to explain what a desktop is and how it works if we start with the layer of granularity above the desktop, the windows station.
What's a windows station?
A windows station is a secure container that contains a clipboard, some global information, and a set of one or more desktops. The interactive window station assigned to the logon session of the interactive user also contains the keyboard, mouse, and display device. The interactive window station is visible to the user and can receive input from the user. All other window stations are non-interactive, which means that they can’t be made visible to the user and can’t receive user input.
What's an interactive desktop?
A desktop is a secure container object that is contained within a window station. There may be many desktops contained within a windows station.
A desktop has a logical display surface and contains windows, menus, and hooks. Only the desktops of the interactive window station can be visible and receive user input. On the interactive window station, only one desktop at a time is active. This active desktop, also referred to as the interactive desktop or input desktop, is the one that is currently visible to the user and that receives user input.
What are Windows messages?
Processes running on Windows interact with the system and other processes using messages. For instance, each time the user hits a key on the keyboard, moves the mouse, or clicks a control such as a scroll bar, Windows generates a message, the purpose of which is to alert the application that a user event has occurred, and deliver the data from that event to the application. Similarly, an application can generate messages as a way of allowing the various windows it controls to communicate with and task each other.
What’s wrong with the way Windows messages are handled within the interactive desktop?
The flaw actually lies in the way one particular Windows message, known as WM_TIMER, operates. WM_TIMER is a Windows message associated with a timer function. By design, a process in the interactive desktop can set up a timer, at the expiration of which another function, known as a callback function, will be executed.
A flaw in WM_TIMER results because it’s possible for one process to send a WM_TIMER message to another process in the interactive desktop as if the message had been sent as a result of a timer function. The first process could set the address of the callback function, with the result being that the second process would execute the callback function specified by the first.
Why does this pose a security vulnerability?
Essentially, the flaw in WM_TIMER would provide a way for one process on the interactive desktop to cause another one to do its bidding. If the second process had higher privileges, this would provide a way for the first to exercise them.
What if the second process had only the same privileges as the first?
It wouldn’t offer any opportunity to gain additional privileges. The flaw only poses a threat in the case where different processes running in the interactive desktop had differing levels of privilege.
I saw a posting Microsoft authored shortly after this issue was reported, in which you said the problem was that processes with differing levels of privilege were running on the interactive desktop. It sounds like you’ve changed your opinion.
We have. When we initially examined the situation, we concluded that the problem here lay solely in the fact that highly-privileged and lower-privileged processes were both present in the interactive desktop. We pointed out that, by design, all processes on the interactive desktop are peers, and stated that we believed the real solution was to not mix processes of varying privileges.
However, upon deeper investigation, we determined that the real answer is somewhat more complicated. It’s possible for a highly privilege process to coexist safely with less privileged processes on the interactive desktop, provided that it’s been properly designed to vet all requests before acting on them. However, the flaw in WM_TIMER would undermine these safeguards even if they were present. As a result, although we still recommend that developers use extreme care before writing a process that has high privileges and runs in the interactive desktop, we believe that in this case the real culprit is the flaw in WM_TIMER.
In your posting, you said that you’d found several Microsoft services that didn’t follow your own guidance, and ran with high privileges in the interactive desktop but didn’t adequately vet requests from other processes. Is this still true?
We did find several processes running with high privileges, and several places in which we could improve the vetting they perform. However, in the end we concluded that none of them could be subverted without the WM_TIMER flaw. Although this patch does deliver changes to some services, we believe that the only real security vulnerability lies in WM_TIMER.
What might an attacker use the vulnerability to do?
An attacker who successfully exploited the vulnerability could, if there was a highly privileged process running in the interactive desktop, create a process that would levy requests upon it. In default configurations of Windows, several such processes are available, running with LocalSystem privileges. Exploiting the vulnerability in such a case would enable the attacker to gain complete control over the system.
Who could exploit the vulnerability?
To exploit the vulnerability, the attacker would need the ability to log onto the system, load a program of his or her choice (one that sent the WM_TIMER message to a highly privileged process, and specified a callback function that would perform some desired task), and run it.
What systems are primarily at risk from the vulnerability?
In general, workstations and terminal servers would be chiefly at risk. Servers would only be at risk if unprivileged users had been given the ability to log onto them and run programs, but best practices strongly mitigate against allowing this for a number of reasons.
Could the vulnerability be exploited from the Internet?
No. The attacker would need the ability to log onto the specific system he or she wished to attack. There is no capability to load and run a program in the interactive desktop remotely.
Wasn’t there a change to the handling of the WM_TIMER message in Windows XP Service Pack 1?
Yes. The WM_TIMER message handling in Windows XP Service Pack 1 was changed and also addresses this issue. We’re delivering a patch for two reasons: to provide the same changes to WM_TIMER for other Windows versions, and to deliver additional changes that have the effect of making certain processes more robust when running in the interactive desktop. Because the patch contains these additional fixes, we recommend that even customers who have applied Windows XP Service Pack 1 also apply the patch.
Are all the changes for Windows 2000 and Windows XP also being made on Windows NT 4.0?
The Windows NT 4.0 patch fixes the vulnerability with WM_TIMER and eliminates the attacks that we’re aware of. However, because of their more modern and robust system architectures, it was possible for us to make additional changes to Windows 2000 and Windows XP that provide added defense in depth that should help protect against related threats in the future.
What does the patch do?
The patch addresses the vulnerability by changing the handling of the WM_TIMER message so that an unregistered callback function can not be called. The patch also includes changes to message handling by some Microsoft provided processes that can run as interactive services.
Patch availability Download locations for this patch Windows NT 4.0:
All except Japanese NEC and Chinese - Hong Kong Japanese NEC Chinese - Hong Kong Windows NT 4.0, Terminal Server Edition:
All Windows 2000: All except Japanese NEC Japanese NEC Windows XP:
32-bit Edition 64-bit Edition
Additional information about this patch Installation platforms:
The Windows NT 4.0 patch can be installed on systems running Service Pack 6a. The Windows NT 4.0, Terminal Server Edition patch can be installed on systems running Windows NT 4.0, Terminal Server Edition Service Pack 6. The Windows 2000 patch can be installed on systems running Windows 2000 Service Pack 1, Service Pack 2, or Service Pack 3. The patch for Windows XP can be installed on systems running Windows XP Gold or Service Pack 1. Inclusion in future service packs: The fix for this issue will be included in Windows 2000 Service Pack 4 and Windows XP Service Pack 2.
Reboot needed: Yes
Patch can be uninstalled: Yes
Superseded patches: None.
Verifying patch installation:
Windows NT 4.0:
To verify that the patch has been installed on the machine, confirm that all files listed in the file manifest in Knowledge Base article 328310 are present on the system. Windows NT 4.0 Terminal Server Edition:
To verify that the patch has been installed on the machine, confirm that all files listed in the file manifest in Knowledge Base article 328310 are present on the system. Windows 2000:
To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows 2000\SP4\Q328310.
To verify the individual files, use the date/time and version information provided in the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows 2000\SP4\Q328310\Filelist. Windows XP:
To verify that the patch has been installed, confirm that the following registry key has been created on the machine: HKLM\Software\Microsoft\Updates\Windows XP\SP2\Q328310.
To verify the individual files, use the date/time and version information provided in the following registry key: HKLM\Software\Microsoft\Updates\Windows XP\SP2\Q328310\Filelist. Caveats: None
Localization: Localized versions of this patch are available at the locations discussed in “Patch Availability”.
Obtaining other security patches: Patches for other security issues are available from the following locations:
Security patches are available from the Microsoft Download Center, and can be most easily found by doing a keyword search for "security_patch". Patches for consumer platforms are available from the WindowsUpdate web site Other information: Support:
Microsoft Knowledge Base article 328310 discusses this issue and will be available approximately 24 hours after the release of this bulletin. Knowledge Base articles can be found on the Microsoft Online Support web site. Technical support is available from Microsoft Product Support Services. There is no charge for support calls associated with security patches. Security Resources: The Microsoft TechNet Security Web Site provides additional information about security in Microsoft products.
Disclaimer: The information provided in the Microsoft Knowledge Base is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.
V1.0 (December 11, 2002): Bulletin Created.