|
|
|
|
| |
| A privilege elevation vulnerability exists in the POSIX operating system component (subsystem). An attacker who successfully exploited this vulnerability could take complete control of an affected system, including installing programs; viewing, changing, or deleting data; or creating new accounts that have full privileges. |
| |
Credit:
The information has been provided by Microsoft Product Security.
The original article can be found at: http://www.microsoft.com/technet/security/bulletin/MS04-020.mspx
|
| |
Vulnerable Systems:
* Microsoft Windows NT Workstation 4.0 Service Pack 6a - Download the update
* Microsoft Windows NT Server 4.0 Service Pack 6a - Download the update
* Microsoft Windows NT Server 4.0 Terminal Server Edition Service Pack 6 - Download the update
* Microsoft Windows 2000 Service Pack 2, Microsoft Windows 2000 Service Pack 3, Microsoft Windows 2000 Service Pack 4 - Download the update
Immune Systems:
* Microsoft Windows XP and Microsoft Windows XP Service Pack 1
* Microsoft Windows XP 64-Bit Edition Service Pack 1
* Microsoft Windows XP 64-Bit Edition Version 2003
* Microsoft Windows Server 2003
* Microsoft Windows Server 2003 64-Bit Edition
* Microsoft Windows 98, Microsoft Windows 98 Second Edition (SE), and Microsoft Windows Millennium Edition (Me)
CVE Information:
CAN-2004-0210
A privilege elevation vulnerability exists in the POSIX subsystem. This vulnerability could allow a logged on user to take complete control of the system. This is possible due to an unchecked buffer in the POSIX subsystem component that can lead to a buffer overflow and complete compromise of the system. The vulnerability was privately disclosed to the vendor. It is highly recommended to download and install the POSIX subsystem update.
Mitigating Factors for POSIX Vulnerability
The following mitigating factors reduce the risk to Microsoft Windows users:
* An attacker must have valid logon credentials and be able to logon locally to exploit this vulnerability. The vulnerability could not be exploited remotely or by anonymous users.
* Windows XP and Windows Server 2003 are not affected by this vulnerability.
Workarounds for POSIX Vulnerability
Microsoft has tested the following workarounds. While these workarounds will not correct the underlying vulnerability, they help block known attack vectors. When a workaround reduces functionality, it is identified below.
* Disable the POSIX subsystem through the registry
This workaround is fully documented in Microsoft Knowledge Base Article 101270.
This article is summarized in the following paragraphs and the following steps demonstrate how to disable the POSIX subsystem.
Note: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk and back it up before modification.
* Click Start, click Run, type "regedt32" (without the quotation marks), and then click OK.
* In Registry Editor, locate the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Subsystems\Posix
* Click the POSIX data value, click Edit, and then click Delete.
* Click OK to confirm the delete, and then restart the system.
Note: To re-enable the POSIX subsystem, recreate the registry key.
Impact of workaround: POSIX programs are disabled until the POSIX subsystem is enabled.
Frequently Asked Questions
What is the scope of the vulnerability ?
This is a privilege elevation vulnerability. An attacker who successfully exploited this vulnerability could take complete control of an affected system, including installing programs; viewing, changing, or deleting data; or creating new accounts that have full privileges.
What causes the vulnerability ?
An unchecked buffer in the POSIX subsystem.
What is the POSIX subsystem ?
You can run applications that are created for the Portable Operating System Interface for UNIX (POSIX) standard under Windows NT 4.0 and Windows 2000. The operating systems provide support for nonnative applications by emulating the environments in which they are designed to be processed. This support is provided through environment subsystems. Except for the Microsoft Win32 subsystem, which is the native environment of Windows, each environment is optional and is used only when a client application requires its services. For more information about POSIX support, visit the following MSDN Library Web Site.
What might an attacker use the vulnerability to do ?
An attacker who successfully exploited this vulnerability could take complete control of the affected system.
Who could exploit the vulnerability ?
To exploit the vulnerability, an attacker must be able to log on locally to a system that has the POSIX subsystem enabled.
How could an attacker exploit the vulnerability ?
To exploit this vulnerability, an attacker would first have to log on to the system. An attacker could then run a specially designed program that could attempt to exploit the vulnerability, and thereby gain complete control over the affected system.
An attacker could also access the affected component through another vector. For example, an attacker could use another program that passes parameters to the vulnerable component (locally or remotely).
What systems are primarily at risk from the vulnerability?
Windows NT 4.0 and Windows 2000 systems are at risk from this vulnerability. Windows XP and Windows Server 2003 do not contain the POSIX subsystem. For more information about the support of POSIX in Windows XP and in Windows Server 2003, see Microsoft Knowledge Base Article 308259.
Could the vulnerability be exploited over the Internet ?
No. An attacker must be able to log on to the specific system that is targeted for attack. An attacker cannot load and run a program remotely by exploiting this vulnerability.
What does the update do ?
The update removes the vulnerability by modifying the way that the POSIX subsystem validates the length of a message before it passes the message to the allocated buffer.
When this security bulletin was issued, had this vulnerability been publicly disclosed ?
No. Microsoft received information about this vulnerability through responsible disclosure. Microsoft had not received any information indicating that this vulnerability had been publicly disclosed when this security bulletin was originally issued.
When this security bulletin was issued, had Microsoft received any reports that this vulnerability was being exploited ?
No. Microsoft had not received any information indicating that this vulnerability had been publicly used to attack customers and had not seen any examples of proof of concept code published when this security bulletin was originally issued.
|
|
|
|
|
|
|
