Export (0) Print
Expand All

Microsoft Security Bulletin MS02-024 - Critical

Authentication Flaw in Windows Debugger can Lead to Elevated Privileges (Q320206)

Published: May 22, 2002 | Updated: February 28, 2003

Version: 1.1

Originally posted: May 22, 2002
Updated: February 28th, 2003

Summary

Who should read this bulletin:
Administrators of Microsoft® Windows NT® 4.0, Windows® 2000 systems.

Impact of vulnerability: 
Elevation of Privilege

Maximum Severity Rating: 
Critical

Recommendation: 
System Administrators should apply the patch to all systems that allow unprivileged users to log onto them interactively.

Affected Software:

  • Microsoft Windows NT 4.0
  • Microsoft Windows NT 4.0 Server, Terminal Server Edition
  • Microsoft Windows 2000

General Information

Technical description:

The Windows debugging facility provides a means for programs to perform diagnostic and analytic functions on applications as they are running on the operating system. One of these capabilities allows for a program, usually a debugger, to connect to any running program, and to take control of it. The program can then issue commands to the controlled program, including the ability to start other programs. These commands would then execute in the same security context as the controlled program.

There is a flaw in the authentication mechanism for the debugging facility such that an unauthorized program can gain access to the debugger. A vulnerability results because an attacker can use this to cause a running program to run a program of her choice. Because many programs run as the operating system, this means that an attacker can exploit this vulnerability to run code as the operating system itself. She could take any action on the system including deleting data, adding accounts with administrative access, or reconfiguring the system.

A successful attack requires the ability to logon interactively to the system, either at the console or through a terminal session. Also, an a successful attack requires the introduction of code to exploit this vulnerability. Because best practices recommends restricting the ability to logon interactively on servers, this issue most directly affects client systems and terminal servers.

Mitigating factors:

  • A successful attack requires the ability to logon interactively to the target machine, either directly at the console or through a terminal session. Best practices strongly militate against ever allowing an unprivileged user to interactively log onto business-critical systems such as ERP servers, database servers, domain controllers and the like. If these recommendations have been followed, the vulnerability would principally pose a threat only to systems like workstations and terminal servers.
  • A successful attack requires that the attacker be able to load code of her choice on the system. Restrictions on a user's ability to load and execute arbitrary code could potentially prevent a successful attack.

Severity Rating:

Internet ServersIntranet ServersClient Systems
Windows NT 4.0 LowModerateCritical
Windows 2000 LowModerateCritical

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. The vulnerability requires interactive logons, which are normally heavily restricted on Internet facing systems and moderately restricted on Intranet systems. In addition, the attack requires the introduction of malicious code to the system.

Vulnerability identifier: CAN-2002-0367

Tested Versions:

Microsoft tested Windows NT 4.0, 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.

What's the scope of the vulnerability?
This is a privilege elevation vulnerability. A malicious user who has the ability to interactively log on to a system and run code of her choice could seek to exploit this vulnerability and pose as any user on the system, including any administrator or the operating system itself.
Because this requires the ability to logon interactively and run a program, the systems most likely to be affected by this vulnerability are client systems and terminal servers, which regularly allow end-users access to the system directly at the keyboard. Internet servers, file and print servers, and application servers such as SQL servers usually restrict the ability to logon interactively, and thus are less likely to be affected by this vulnerability.

What causes the vulnerability?
The vulnerability results because of a flaw in how access to the debugging facility in Windows is validated. Due to a flaw in how requests to attach to the system debugger are authenticated, it's possible for unauthorized programs to gain access to it.

What is the debugging facility in Windows?
The debugging facility in Windows provides a way for system administrators and developers to troubleshoot programs running on Windows.
The Windows debugging facility differs from those found in development environments such as Visual Studio in that it allows for viewing and analysis of the code as it is running on the operating system in real-time. This can help developers and engineers to view and diagnose issues that are specific to a particular machine or configuration by allowing them to interrogate the code directly on the system.

How does the Windows debugging facility work?
At the root of the ability to debug code when running is the ability for one program to "attach" to another. In almost every case, this will be a debugging program or debugger, that then connects or "attaches" to the running program, or debuggee.
"Attaching" provides the means by which the debugger can then control the program being debugged. Since the process of troubleshooting requires the ability for the debugger to completely manipulate the debuggee program, the debugging facility grants the debugger the same level of control over the running program as it has itself.

What's wrong with the debugging facility in Windows?
Before allowing a debugger to attach to another program, the Windows debugger ensures that the debugger has the appropriate privileges. However, there is a flaw in how the authentication is performed, with the result that a program could be able to attach to the debugger without having the proper privileges to do so.

What could this vulnerability enable an attacker to do?
One of the capabilities that the debugger grants to applications that attach to running programs is the ability to command the running program to in turn launch new programs. When these programs are launched, they run in the security context of the launching program.
This means that this vulnerability could allow an attacker to run a program of her choosing on the system with the same privileges as any other program currently running on the system. Since a number of programs run on the system in the context of the operating system, an attacker could use this vulnerability to make her program run as if it were the operating system.
A program run in this security context would have complete control over the machine and would be able to take any action that the operating system itself could take. This includes but is not limited to adding accounts with administrative privileges, deleting critical system files, and changing security settings.

How could an attacker exploit this vulnerability?
An attacker could seek to exploit this vulnerability by writing a program that would attempt to connect to the debugging facility in Windows in a way that exploits this flaw. The attacker would most likely have her program then attempt to connect to a well-known program that runs with SYSTEM level privileges and command that program to launch a program of her choice.
Because this cannot be exploited without the ability to logon and the ability to introduce hostile code to the system, best practices that limit users' ability to logon and load programs, in accordance with the rule of least privilege, can mitigate against the chances for a successful attack.

Would this give an attacker control over the network?
In most cases, this would not. However, it will depend on the machine on which a user has logon rights. For example, if an unprivileged user were able to logon to a domain control and exploit this vulnerability, she could use this to achieve administrative privileges on the domain itself.
However, because domain controllers contain sensitive, network-wide information like this, they are usually configured in accordance with least privilege best practices and, thus, non-administrative users do not have the ability to interactively logon to them.

What does the patch do?
The patch eliminates the vulnerability by implementing proper validation for requests to attach to the debugging system.

Download locations for this patch

Additional information about this patch

Installation platforms:

  • Windows NT 4.0:

    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.
  • Windows 2000:

    This patch can be installed on systems running Windows 2000 Service Pack 1 or Windows 2000 Service Pack 2

    Inclusion in future service packs:

    • The fix for this issue will be included in Windows 2000 Service Pack 3.

    Reboot needed: Yes

    Superseded patches: None.

    Verifying patch installation: Windows NT 4.0 and Windows NT 4.0 Terminal Server Edition:

    • 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\Windows NT\CurrentVersion\Hotfix\Q320206.

    • To verify the individual files, consult the file manifest in Knowledge Base article Q320206

    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\Q320206.

    • 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\Q320206\Filelist

    Caveats:

    None

    Localization:

    Localized versions of this patch are under development. When completed, they will be available at the locations discussed in "Obtaining other security patches".

    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 Q320206 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.

Revisions:

  • V1.0 (May 22, 2002): Bulletin Created.
  • V1.1 (February 28, 2003): Updated download links to Windows Update.

Built at 2014-04-18T13:49:36Z-07:00

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2015 Microsoft