• Article

Security Bulletin

Microsoft Security Bulletin MS00-070 - Critical

Patch Available for Multiple LPC and LPC Ports Vulnerabilities

Published: October 03, 2000

Version: 1.0

Originally posted: October 03, 2000

Summary

Microsoft has released a patch that eliminates several security vulnerabilities in Microsoft® Windows NT® 4.0 and Windows® 2000. The vulnerabilities could allow a range of effects, from denial of service attacks to, in some cases, privilege elevation.

Affected Software:

  • Microsoft Windows NT 4.0 Workstation
  • Microsoft Windows NT 4.0 Server
  • Microsoft Windows NT 4.0 Server, Enterprise Edition
  • Microsoft Windows NT 4.0 Server, Terminal Server Edition
  • Microsoft Windows 2000 Professional
  • Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Datacenter Server

General Information

Technical details

Technical description:

Several vulnerabilities have been identified in the Windows NT 4.0 and Windows 2000 implementations of LPC and LPC ports:

  • The "Invalid LPC Request" vulnerability, which affects only Windows NT 4.0. By levying an invalid LPC request, it would be possible to make the affected system fail.
  • The "LPC Memory Exhaustion" vulnerability, which affects both Windows NT 4.0 and Windows 2000. By levying spurious LPC requests, it could be possible to increase the number of queued LPC messages to the point where kernel memory was depleted.
  • The "Predictable LPC Message Identifier" vulnerability, which affects both Windows NT 4.0 and Windows 2000. Any process that knows the identifier of an LPC message can access it; however, the identifiers can be predicted. In the simplest case, a malicious user could access other process' LPC ports and feed them random data as a denial of service attack. In the worst case, it could be possible under certain conditions to send bogus requests to a privileged process in order to gain additional local privileges
  • A new variant of the previously-reported "Spoofed LPC Port Request" vulnerability. This vulnerability affects Windows NT 4.0 and Windows 2000, and could, under a very restricted set of conditions, allow a malicious user to create a process that would run under the security context of an already-running process, potentially including System processes.

Because LPC can only be used on the local machine, none of these vulnerabilities could be exploited remotely. Instead, a malicious user could only exploit them on machines that he could log onto interactively. Typically, workstations and terminal servers would be chiefly at risk, because, if normal security practices have been followed, normal users will not be allowed to log onto critical servers interactively. This also means that, even in the worst case, the vulnerability would only confer additional local - not domain - privileges on the malicious user.

Frequently asked questions

What's this bulletin about?
Microsoft Security Bulletin MS00-070 announces the availability of a patch that eliminates several vulnerabilities in Microsoft® Windows NT® 4.0 and Windows® 2000. Microsoft is committed to protecting customers' information,and is providing the bulletin to inform customers of the vulnerabilities and what they can do about them.

What's the scope of the vulnerabilities?
The vulnerabilities discussed here fall into two primary groups.

  • Several of the vulnerabilities would enable denial of service attacks that could cause an affected system to fail.
  • Others would enable a malicious user to gain unwarranted privileges on a machine, either by impersonating another user or a system process. In the latter case, this could allow a malicious user to conduct a privilege elevation attack and gain administrative rights on a machine.

These vulnerabilities could only be used to attack a machine that the malicious user could log onto interactively. As a result, the machines primarily at risk would be machines such as workstations and terminal servers - if normal security precautions have been followed, security-critical servers will not allow normal users to log onto them interactively.

What causes the vulnerabilities?
The vulnerabilities result because of two flaws that underlie the LPC and LPC Ports implementations in Windows NT 4.0 and Windows 2000.

  • The Windows NT 4.0 implementation does not properly handle some cases in which processes don't behave as expected. If a process makes LPC requests in an invalid order, or using invalid parameters, it could cause the system to fail.
  • The means by which LPC Ports are identified in Windows NT 4.0 and Windows 2000 is predictable, and this could allow one process to access an LPC port belonging to another process.

What is LPC?
LPC (Local Procedure Call) is a message-passing service provided by Windows NT 4.0 and Windows 2000 that allows threads and processes to communicate with each other. Anytime a client process needs to request services from a server process, there has to be a way for the two processes to communicate with each other - that is, there must be a way for the client process to make requests of the server, for the server to send responses to the client, and for each to determine their mutual status. When the client and server processes are located on different machines, RPC (Remote Procedure Call) is used. When they are located on the same machine, LPC can be used. The advantage of using LPC is that it's fast. Because the processes are located on the same machine, certain efficiencies can be gained to speed up the communications. For instance, it's possible under LPC for the two processes to communicate via a shared memory segment - rather than passing messages to each other, one process puts a message in the shared segment and sends a signal to the other party, which then reads the message from the shared segment.

What are LPC Ports?
Every LPC has a collection of communications channels called LPC ports. Each port carries one type of communication - for instance, an LPC will always have a port that's used to allow one client to send messages to the server, another port that allows the server to send messages to each client, as well as other ports that, for instance, allow threads within a process to coordinate their requests.

What's wrong with the LPC and LPC ports implementations?
As discussed above in "What causes these vulnerabilities?", there are two overall problems with the LPC and LPC ports implementations. These problems give rise to four specific vulnerabilities, discussed at greater length below:

  • The "Invalid LPC Request" vulnerability.
  • The "LPC Memory Exhaustion" vulnerability.
  • The "Predictable LPC Message Identifier" vulnerability.
  • A new variant of the previously-reported "Spoofed LPC Port Request" vulnerability.

What's the "Invalid LPC Request" vulnerability?
The Windows NT 4.0 implementation of LPC doesn't correctly handle cases in which certain calls are made out of order, or without the expected parameters. If a malicious user created a process that made such calls, it could cause the system to fail.

Does this vulnerability affect Windows 2000?
No. It only affects Windows NT 4.0

What machines could the malicious user attack via this vulnerability?
Because it involves the LPC mechanism, he could only attack a machine that he could interactively log onto. This vulnerability could not be used to attack a remote machine.

Why would a malicious user want to crash the machine he's using?
In most cases, it would be counterproductive for him to crash his own machine. For instance, if a malicious user exploited this vulnerability on a workstation, the damage would be entirely self-inflicted and would affect only him. However, if he could interactively log onto a machine that's shared between several users, he might choose to make it fail as a denial of service attack against the other users. Terminal servers would be chiefly at risk here, because normal users are typically allowed to log onto them interactively. Other servers, such as domain controllers, print/file servers, ERP servers, database servers, and others would be unlikely targets for such an attack if security best practices - which strongly militate against allowing unprivileged users to log onto them interactively - have been followed.

How could an affected machine be put back into service?
The machine could be put back into service by rebooting it.

How does the patch eliminate this vulnerability?
The patch eliminates the vulnerability by causing the Windows NT 4.0 LPC implementation to reject the requests at issue here. This is an appropriate response, because the requests are invalid.

What's the "LPC Memory Exhaustion" vulnerability?
Both the Windows NT 4.0 and Windows 2000 implementations of LPC allocate message-storage memory from a pool called the LPC Zone. Whenever the volume of messages exceeds the capacity of the LPC Zone, additional memory is diverted from the kernel to the LPC Zone. By design, this memory should be returned to kernel memory when it's no longer needed. However, by sending a specific type of malformed LPC request, it would be possible to prevent this from happening. The would provide an opportunity for a malicious user to slow or stop the system's performance by diverting some or all of the kernel memory.

What machines would be at risk from this vulnerability?
Terminal servers would be primarily at risk, for reasons similar to those discussed above regarding the "Invalid LPC Request" vulnerability. It would do little good for a malicious user to mount a denial of service attack against his own workstation, and, if security best practices have been followed, he would be unable to interactively log onto a security-critical server.

How could an affected machine be put back into service?
The administrator could return the machine to normal service by rebooting the machine.

How does the patch eliminate this vulnerability?
The patch eliminates the vulnerability by ensuring that all kernel memory diverted to the LPC Zone is restored as soon as the requesting process no longer needs it.

What's the "Predictable LPC Message Identifier" vulnerability?
In both the Windows NT 4.0 and Windows 2000 implementations of LPC, any process that knows the identifier for an LPC message can use it. A vulnerability results because the identifier can be predicted. This would allow a process to interfere with the LPC communications belonging to another process.

What would this allow a malicious user to do?
The vulnerability would enable a malicious user to mount three types of attacks:

  • Denial of service. In the simplest case, a rogue process could pose as either the client or server, and simply send random data to them, as a way of causing either the client or server to fail.
  • Eavesdropping. If the client and server jointly shared a memory segment as a message-passing mechanism, the rogue process could view the data stored there.
  • Privilege elevation. If the malicious user could identify a system process that had an existing LPC connection with a privileged thread, he could potentially spoof the client and make requests that he otherwise wouldn't be able to. The specific actions he could take would depend on what processes were running, and what they allowed him to do.

What machines would be at risk from this vulnerability?
Terminal servers would be primarily at risk from denial of service attacks via this vulnerability, for similar reasons as discussed above with regard to the "Invalid LPC Request" and "LPC Memory Exhaustion" vulnerabilities. It's also likely that an eavesdropping attack would be most productive if mounted on a terminal server, since it could allow the malicious user to eavesdrop on other user's processes. If this vulnerability were exploited as a privilege elevation attack, both terminal servers and workstations would be prime targets. However, servers that, per normal security practices, do not allow normal users to log onto them would be unaffected by this vulnerability regardless of whether it's exploited as a denial of service, eavesdropping or privilege elevation attack. If the malicious user were unable to log onto the machine interactively, he could not exploit the vulnerability.

What privileges could a malicious user gain through this attack?
It would depend on the specific processes running on the machine, and the type of privileges they could confer. The vulnerability does not provide a way to start a desired process, so the malicious user would need to find an already-running process that he could subvert. Even in the worst case, though, this vulnerability would only allow privileges on the local machine to be elevated. That is, if the malicious user exploited the vulnerability on a workstation, he could gain privileges on the workstation - but he could not use this vulnerability to directly elevate his domain privileges.

What does the patch do?
The patch eliminates the vulnerability by causing LPC messages to deny requests when the requester isn't the owner of the message.

What is the new variant of the "Spoofed LPC Port Request" vulnerability?
The "Spoofed LPC Port Request" vulnerability, originally discussed in Microsoft Security Bulletin MS00-003, involves the ability of a malicious user to create both a client and server process and then, by manipulating the LPC request, cause them to run in an elevated security context - potentially that of the System itself. The new variant provides a way to exploit the vulnerability even after the patch provided in MS00-003 has been applied. However, the new variant has some significant restrictions regarding the circumstances under which it could be exploited.

What are the restrictions?
There are two restrictions:

  • The new variant wouldn't allow the malicious user to cause his process to run in any desired security context. Instead, it would only allow the new process to impersonate one of the already-running processes on the machine, and only if the malicious user could predict its LPC port identifier.
  • The vulnerability could only be exploited if the malicious user timed his impersonation request to occur at the same time that the target process made a particular LPC call. However, the malicious user would have no way to know when such a call occurred.

What machines would be at risk from this vulnerability?
Terminal servers and workstations would be prime targets. Servers that, per normal security practices, do not allow normal users to log onto them would be unaffected by this vulnerability. As discussed above, if the malicious user were unable to log onto the machine interactively, he could not exploit the vulnerability.

What privileges could a malicious user gain through this attack?
It would depend on the specific processes running on the machine. The vulnerability does not provide a way to start a desired process. In any event, this vulnerability would only allow privileges on the local machine to be elevated. That is, if the malicious user exploited the vulnerability on a workstation, he could gain privileges on the workstation - but he could not use it to directly elevate his domain privileges.

What does the patch do?
The patch eliminates the vulnerability by regulating the ability of a process to impersonate privileged processes.

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

How do I use the patch?
The Knowledge Base article contains detailed instructions for applying the patch to your site.

How can I tell if I installed the patch correctly?
Knowledge Base article Q266433 provides a manifest of the files in the patch package.The easiest way to verify that you've installed the patch correctly is to verify 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?

  • Microsoft has delivered a patch that eliminates the vulnerability.
  • Microsoft has provided a security bulletin and this FAQ to provide customers with a detailed understanding of the vulnerability and the procedure to eliminate it.
  • Microsoft has sent copies of the security bulletin to all subscribers to the Microsoft Product Security Notification Service, a free e-mail service that customers can use to stay up to date with Microsoft security bulletins.
  • Microsoft has issued a Knowledge Base article explaining the vulnerability and procedure in more detail.

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

How do I get technical support on this issue?
Microsoft Product Support Servicescan provide assistance with this or any other product support issue.

Patch availability

Download locations for this patch

Additional information about this patch

Installation platforms: Please see the following references for more information related to this issue.

  • Microsoft Knowledge Base (KB) article Q266433, https:

Other information:

Acknowledgments

Microsoft thanks BindView's Razor Team for reporting these issues to us and helping us protect our customers. The issues involved in these vulnerabilities required several months of detailed engineering, and BindView worked closely with us throughout the process. We'd like to thank them for their ongoing commitment to responsible reporting practices.

Support: This is a fully supported patch. Information on contacting Microsoft Product Support Services is available at </https:>https:.

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.

Revisions:

  • October 03, 2000: Bulletin Created.

Built at 2014-04-18T13:49:36Z-07:00 </https:>