Microsoft Security Bulletin (MS00-003): Frequently Asked Questions

What's this bulletin about?
Microsoft Security Bulletin MS00-003 announces the availability of a patch that eliminates a vulnerability in Microsoft® Windows NT® 4.0. The vulnerability could allow a user to gain inappropriate privileges on a Windows NT 4.0 machine. Microsoft is committed to protecting customers' information, and is providing the bulletin to inform customers of the vulnerability and what they can do about it.

What's the scope of the vulnerability? 
This is a privilege elevation vulnerability. A malicious user who could interactively log on to a Windows NT 4.0 machine and run a program could pose as any other user on the machine, including the administrator or the system itself.
The machines most likely to be affected by this vulnerability are Windows NT 4.0 workstations and terminal servers, because they typically allow normal users to interactively log onto them. Security-critical machines such as domain controllers, ERP servers, print and file servers, and SQL servers typically do not allow normal users to interactively log onto them and, if this were the case, would not be at risk from this vulnerability.
The vulnerability would allow a normal user to assume any desired level of privilege on the machine that was compromised. In the case of a compromised workstation, it's likely that the malicious user could not extend control to the rest of the network. However, if he or she compromised a domain controller, he or she would gain de facto control of the domain.

What causes the vulnerability? 
A flaw in a function that supports so-called LPC Ports would allow a malicious user to request services in the security context of another user, or as the operating system itself. The function is designed to allow a server thread to impersonate a client thread on the same machine and take action on its behalf. The function does perform validation checks to ensure that the request is legitimate, but it is possible to spoof these checks through a fairly complicated scenario. A malicious user who created both the client and server threads could spoof the server's validation checks and make it appear that the client thread actually belongs to a higher-privilege user. This would allow the malicious user to request any desired service in the security context of any desired user.

What are LPC Ports? 
The LPC Ports facility is one method of making local procedure calls (LPC) on a machine. LPC is a message-passing service provided by Windows NT that allows threads and processes on the same machine to communicate with each other. Client threads need a way to request services from server threads, and server threads need a way to return status information to a client that made a request. Rather than requiring every thread and process to implement their own communications services, Windows NT provides a standardized service, LPC, that all thread and processes can use.
The fact that this vulnerability lies in a function associated with LPC is significant. Because LPC only allows threads on the same machine to communicate, it serves to limit the scope of the vulnerability to the local machine only.

Is this a vulnerability in the LPC Ports facility? 
No, there is no problem with LPC Ports per se. The flaw is entirely within one function in the LPC Ports API set.

What would this vulnerability let a malicious user do? 
A malicious user could exploit this vulnerability in two ways. The most serious outcome is that the user could gain additional privileges on the machine. For instance, he or she could add himself or herself to the local Administrators group, after which point they could take any desired action on the machine.
Alternatively, a malicious user could exploit this vulnerability in order to levy requests as another user, simply as a way of covering his or her tracks when taking some unauthorized action. Any audit logs would show that the other user had taken the action rather than the malicious user.

Could this vulnerability be exploited accidentally? 
No. Exploiting this vulnerability requires a very specific series of steps that have no legitimate purpose. They would only be taken by a malicious user hoping to exploit this vulnerability.

Could this vulnerability be exploited remotely? 
No. As discussed above, the specific function call at issue here can only be used to create threads on the local machine, so a malicious user could only use it to attack a machine that he or she can log onto interactively.

What machines are at greatest risk from this vulnerability? 
Machines that allow normal users to interactively log onto them and run arbitrary programs are at greatest risk from this vulnerability. The machines primarily at risk would be Windows NT 4.0 workstations and terminal servers.
If recommended security practices are followed, security-critical servers such as domain controllers, ERP servers, print and file servers, database servers, and web servers would not allow normal users to interactively log onto them, and hence would not be at risk.

What risk does this vulnerability pose to my network? 
The vulnerability would allow a malicious user to assume any desired level of privilege on the specific machine that he or she compromised. The risk to the network at large would depend on the role that the machine plays on the network. If a workstation or terminal server were compromised, it would likely pose little risk to the network at large. By default, even a local administrator has no special domain privileges.
However, if a domain controller or other machine that stores domain administrative information locally were compromised, the malicious user could take advantage of it to extend control beyond the local machine. This is, however, a bit of a chicken-and-egg issue. The presence of domain administrative information on such machines is the primary reason why recommended security practices militate against giving normal users the ability to interactively onto them.

Does this vulnerability affect Windows 2000? 
No.

What does the patch do? 
The patch changes how the affected API call validates calls to it, and prevents the spoofing attack at issue here.

Where can I get the patch? 
The download location for the patch is provided in the "Patch Availability" section of the security bulletin.

How can I tell if I installed the patch correctly?
Knowledge Base article 247869 provides a manifest of the files in the patch package. The easiest way to verify that you've installed the patch correctly is to check that these files are present on your computer, and have the same sizes and creation dates as shown in the KB article.

What is Microsoft doing about this issue?

Where can I learn more about best practices for security?
The Microsoft Security web site is the best to place to get information about Microsoft security.

How do I get technical support on this issue?
Microsoft Technical Support http://support.microsoft.com/contactussupport/?ws=support can provide assistance with this or any other product support issue.

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.

Top of page