Microsoft has reissued the patch for NT4.0 and NT 4.0 TSE. Why?
Subsequent to the bulletin originally being posted, 2 separate problems were identified with the NT 4.0 and NT 4.0 TSE patches. Microsoft updated the bulletin to provide details of these problems, which are discussed further below, and to include download locations to the updated patches.
What was the problem with the Windows NT 4.0 patch?
The original Windows NT 4.0 patch had an error that caused certain Windows NT 4.0 systems to fail. Microsoft has reissued the Windows NT 4.0 patch to correct this problem.
What was the problem with the Windows NT 4.0 TSE patch?
A patch installer error meant that the correct files were not being installed on multi processor systems. This meant that under certain configurations, these systems were failing. The installer correctly patched single processor machines - there error was only evident on multi processor systems. Microsoft has re-issued the Windows NT 4.0 TSE patch to correct this problem.
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.
