Microsoft Security Bulletin MS01-007 - Critical

Network DDE Agent Requests Can Enable Code to Run in System Context

Published: February 05, 2001 | Updated: July 10, 2003

Version: 2.2

Originally posted: February 05, 2001
Updated: July 10, 2003

Summary

Who should read this bulletin:
System administrators using Microsoft® Windows® 2000 servers or workstations.

Impact of vulnerability:
Privilege elevation

Recommendation:
System administrators should install the patch on all Windows 2000 on which unprivileged users are allowed to load and run programs, and consider applying it to all Windows 2000 web servers as a precautionary measure.

Affected Software:

  • Microsoft Windows 2000 Professional
  • Microsoft Windows 2000 Server     
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Datacenter Server

General Information

Technical details

Technical description:

Network Dynamic Data Exchange (DDE) is a technology that enables applications on different Windows computers to dynamically share data. This sharing is effected via communications channels called trusted shares, which are managed by a service called the Network DDE Agent. By design, processes on the local machine can levy requests upon the Network DDE Agent, including ones that indicate what application should be run in conjunction with a particular trusted share. However, a vulnerability exists because, in Windows 2000, the Network DDE Agent runs using the Local System security context and processes all requests using this context, rather than that of the user. This would give an attacker an opportunity to cause the Network DDE Agent to run code of her choice in Local System context, as a means of gaining complete control over the local machine.

Microsoft recommends that customers using Windows 2000 workstations or who allow unprivileged users to run code on Windows 2000 servers apply the patch immediately. In addition, customers operating Windows 2000 web servers should consider applying the patch to those machines as well, as a precautionary measure. If an attacker were able to gain the ability to run code in a restricted context on a web server via another vulnerability, this vulnerability would provide a way to immediately elevate her privileges and cause broader damage.

Mitigating factors:

  • In order to exploit this vulnerability, the attacker would need the ability to run a program on an affected machine that would levy the appropriate requests. However, best practices strongly recommend against ever allowing unprivileged users to run code on security-critical machines such as domain controllers and other servers; if these recommendations have been followed, such machines would not be at risk.
  • Workstations and terminal servers are likely to be the machines primarily affected by the vulnerability. This would tend to limit the damage that could be done via this vulnerability because, in most cases, even gaining complete control of either type of machine would not convey any additional privileges on the domain.

Vulnerability identifier: CAN-2001-0015

Frequently asked questions

What's the scope of the vulnerability?
This is a privilege elevation vulnerability. An attacker could exploit this vulnerability to run commands and programs with the privileges of the operating system itself. This would enable her to take virtually any action she desired on the affected machine. There are two significant limitations on the scope of the vulnerability:

  • It could only be exploited by an attacker who had the ability to run code of her choice on the affected machine. If best practices have been followed, and unprivileged users are not allowed to run code on servers and other security-critical machines, the vulnerability would pose a risk only to workstations or terminal servers.
  • Even gaining complete control of a workstation or terminal server would not confer any elevated privileges on the domain.

What causes the vulnerability?
The vulnerability results because a process running on the local machine can send a message to the Network DDE Agent that will cause it to start an executable specified within the message. The executable would run using the security context of the Network DDE Agent, which runs in Local System context.

What's Network DDE?
Network Dynamic Data Exchange (DDE) is a technology that enables applications running on different computers to dynamically share information. For instance, using Network DDE, an instance of Word running on Computer A could dynamically link to an instance of Excel running on Computer B, and display a document that's a blend of information from both applications.

What's the Network DDE Agent?
In Network DDE, the client and server applications communicate via a channel known as a trusted share. A Windows service called the Network DDE Agent provides the communications services that allow trusted shares to operate, as well as effecting the creation, deletion and management of trusted shares when needed. The vulnerability results because of a flaw in the Network DDE Agent.

What's wrong with the Network DDE Agent?
In previous versions of Windows systems, the Network DDE Agent ran in the security context of the user. As a result, it was safe to allow it to accept requests from processes running on the local machine. After all, the processes were already running in the user's security context, and couldn't gain any privileges by levying requests to the Network DDE Agent. In Windows 2000, the Network DDE Agent was moved into a component that runs as part of the operating system, but it would still accept requests from processes on the local machine. Under the new conditions, a process could levy a request that would be executed in the Local System security context.

You said above that the Network DDE Agent manages trusted shares. Why does this allow code to be executed?
Among the requests that the Network DDE Agent will accept is one that calls for a trusted share to be activated. Included in the request is the name of the application that's associated with the share. When the Network DDE Agent receives such a request, it starts the application. An attacker could write a program that levied a request to the Network DDE Agent and specified an executable of her choice as the one associated with a particular trusted share. This would cause the Network DDE Agent to execute that code in the Local System security context.

Suppose there were no trusted shares on the machine. Could the attacker levy the request then?
Trusted shares are a prerequisite for the attack, but this wouldn't necessarily deter the attacker. There are three trusted shares on Windows 2000 systems by default. Even if these had been removed, the user could create new ones using the Network DDE Share Manager.

If an attacker exploited this vulnerability, what would she be able to do?
Local System privileges allow a piece of code to function as part of the operating system. With these privileges, the attacker's code could do literally anything on the local machine. For instance, it could add her to the local Administrators group, install new operating system components, or simply reformat the hard drive.

Would the vulnerability enable the attacker to gain any privileges on the domain?
It would depend on the particular machine that she compromised. By itself, the vulnerability would only enable the attacker to elevate her privileges on the local machine. Even gaining complete control of a machine like a workstation or member server typically wouldn't grant the attacker any greater privileges on the domain. However, the compromised machine could serve as a beachhead from which the attacker would try other attacks in an effort to extend her control. Of course, if she were able to exploit this vulnerability on a domain controller, it would, by definition, give her complete control over the domain. As we'll see below, though, best practices would protect machines like domain controllers from this vulnerability.

Could the vulnerability be exploited remotely?
No. The mechanism by which the request would be transmitted to the Network DDE Agent only operates on the local machine. The attacker couldn't run a program on one machine that would exploit the vulnerability on another machine. This is an important point, because it would tend to reduce the risk this vulnerability poses to servers and other sensitive machines. The attacker would need the ability to start a program of her choice on an affected machine, but best practices strongly recommend against ever allowing unprivileged users to run programs on machines like domain controllers, database servers, ERP servers, print and file servers, and so forth. Thus, if best practices have been followed, the vulnerability would be largely limited to workstations and terminal servers.

Does this vulnerability affect Windows NT 4.0?
No. In Windows NT 4.0, the Network DDE Agent ran in the user's own security context, so the vulnerability didn't exist.

Who should use the patch?
Microsoft recommends that all Windows 2000 users consider installing the patch. However, we urge customers using Windows 2000 workstations or terminal servers, and those who allow unprivileged users to run code on Windows 2000 servers to apply the patch immediately. We also recommend that customers operating Windows 2000 web servers consider installing the patch, strictly as a precautionary measure. Web servers should, of course, never allow unprivileged users to execute code. However, if an attacker compromised a web server through another vulnerability and gained the ability to run code on it, she might use this vulnerability to extend her control over it.

What does the patch do?
The patch eliminates the vulnerability by causing the Network DDE Agent to service all requests in the security context of the requester.

Patch availability

Download locations for this patch

Additional information about this patch

Installation platforms:

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

Inclusion in future service packs:

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

Verifying patch installation:

  • 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\SP3\Q285851.

  • 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\SP3\Q285851\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:

Acknowledgments

Microsoft thanks Dildog of @Stake (https://www.atstake.com) for reporting this issue to us and working with us to protect customers.

Support:

  • Microsoft Knowledge Base article Q285851 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 (February 05, 2001): Bulletin Created.
  • V2.0 (February 09, 2001): Bulletin revised to provide updated information regarding terminal servers. Contrary to the original version of the bulletin, terminal servers are affected by the vulnerability.
  • V2.1 (August 15, 2001): Bulletin revised to note that a new version of the patch was released to address a post-SP2 packaging issue, as discussed in Q299549. (Both the old and new versions of the patch protect the machine from the vulnerability in this bulletin.) Registry key data and patch applicability sections have been updated appropriately.
  • V2.2 (July 10, 2003): Corrected links to Windows Update in Additional Information.

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