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.
