Security TechCenter > > Microsoft Security Program: Frequently Asked Questions: Microsoft Security Bulletin (MS99-041)

Microsoft Security Program: Frequently Asked Questions: Microsoft Security Bulletin (MS99-041)

What's this bulletin about?
This bulletin announces the availability of a tool that eliminates a vulnerability in Microsoft® Windows NT® 4.0. The vulnerability could allow a user to gain administrative privileges on a Windows NT machine under certain conditions. Microsoft takes security seriously, and is providing the bulletin to inform customers of the vulnerability and what they can do about it.

What's the scope of the vulnerability?
This is a privilege elevation vulnerability. A user could exploit this vulnerability to gain additional privileges on a Windows NT Workstation or Server. Specifically, they could cause arbitrary code to execute in place of the Remote Access Connection Manager, which runs in a highly-privileged security context. This would allow the attacker to take virtually any action on the machine.
The chief limitation on this vulnerability is that it can only be exploited by a malicious user who can authenticate to the target machine. That is, the malicious user would need to have a valid userid and password for some account on the machine. It does not matter how powerful an account; even a Guest account would be sufficient. It would be easiest to exploit this vulnerability on a machine that allows the malicious user to interactively log on; however, it also is possible to mount this attack remotely under certain conditions, as discussed below.
The privileges that a user could gain would depend on the specific machine that was compromised. If a workstation were compromised, the malicious user would gain complete control over it, but could not directly use this vulnerability to extend control to other machines. On the other hand, if a critical machine like a domain controller were compromised, the malicious user could gain control over the entire network.

What is the vulnerability?
The vulnerability lies in the security descriptor for the Remote Access Connection Manager, also known as RASMAN. By default, the security descriptor's value would allow any user to request that the Service Control Manager change the service parameters for RASMAN. By changing the parameters, a malicious user could cause code of his or her choosing to execute instead of the actual RASMAN code.

What is the Remote Access Connection Manager?
RASMAN, the Remote Access Connection Manager, is a service that allows administrators to manage dial-up connections. This vulnerability has nothing to do with RASMAN itself, though; it results solely because there is an opportunity for a malicious user to cause other code to run in place of RASMAN.

What is the Service Control Manager?
The Service Control Manager is an administrative tool provided in Windows NT that allows system services to be created or modified.

What's a security descriptor?
Security Descriptors control access to operating system objects. Among the objects that they apply to are services, including RASMAN. A security descriptor includes a Discretionary Access Control List, or DACL; this is a list of Access Control Entries, or ACEs. Each ACE specifies the particular rights that one user or group has with respect to the object. The DACL therefore comprises the entire list of rights that all users and groups have with respect to the object.

What's wrong with the security descriptor for RASMAN?
Like other services, RASMAN's security descriptor (specifically, the DACL in the security descriptor) should only allow administrators to manage it. However, there is an erroneous ACE in the DACL for RASMAN, which allows any user to manage RASMAN via the Service Control Manager.
A malicious user could exploit this situation by changing the ImagePath parameter for RASMAN - this parameter specifies the executable code for the service. Changing this parameter would cause different code to execute in place of RASMAN. Significantly, the new code would run in System context, which would allow the code to take virtually any action on the computer.

Does this vulnerability mean that a user could change the registry values that specify RASMAN's parameters?
Not directly. Keep in mind that registry entries are objects, and have their own permissions. The permissions on RASMAN's registry entries are correct, and would not allow a normal user to change them. However, because of the inappropriate DACL in RASMAN's security descriptor, a malicious user could achieve the same effect by using the Service Control Manager to change the RASMAN parameters.

Could this vulnerability be exploited remotely?
Yes. There are two parts to the attack: changing the RASMAN parameters and providing the code that would run in place of RASMAN. The first of these would be relatively simple to exploit remotely. If the malicious user can perform a network logon to a Windows NT machine, he or she would be able to change the RASMAN parameters remotely. Many machines allow network logons under some userid, and it is important that network administrators use the tool to eliminate the vulnerability on all such machines.
The second part of the attack would be much more difficult to accomplish remotely. It would be possible under certain conditions to cause code that resides on a remote machine to run instead of the RASMAN service, but it would be much more difficult to do this. It would require the administrator to have configured the system in very specific (and normally inadvisable) ways, via configuration options that normally would be out of the malicious user's control.
It is important to understand that these two part of the attack are independent of each other. Even if the malicious user could not perform a network logon, he or she might still be able to log on interactively and then remote the arbitrary code. Likewise, even if he or she couldn't remote the arbitrary code, they might be able to change the RASMAN parameters remotely and use existing code on the target machine for malicious purposes.

Could this vulnerability be exploited against any other services?
No. It's only RASMAN's security descriptor that contains the inappropriate DACL.

The RASMAN service is not started on my machine. Could I be affected?
Yes. A variety of conditions can cause a service to start, and it might not be obvious when one of them occurs.

Is this a vulnerability in RAS?
No. There is no vulnerability in the RAS functionality. This problem results because of inappropriate permissions on a service; it just happens that the service in question is associated with RAS. RAS itself, including its security features, is not affected by this vulnerability.

How do I eliminate the vulnerability?
Microsoft has developed a tool that will reset the DACL in RASMAN's security descriptor to the appropriate value.

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

What machines should I run the tool on?
You should run the tool against any machine in your network that allows unprivileged users to perform either interactive or network logons under any security context.

Will Windows NT 4.0 Service Pack 6 correct this vulnerability?
No. When this vulnerability was discovered, Service Pack 6 was too far advanced in its development to incorporate the change. However, the fix will be included in Service Pack 7.

If I run the tool today, will I need to re-run it after I install Service Pack 6?
No. SP6 will not change the DACL on RASMAN. If you were vulnerable before installing SP6, you'll still be vulnerable after installing it; if you run the tool today, you won't need to run it again after installing SP6.

How do I use the tool?
The tool can be used to eliminate the vulnerability in either the local machine or a remote machine.

  • To run the vulnerability on the local machine, just run the tool from the command line with no parameters, e.g., fixrasi.
  • To eliminate the vulnerability on a remote machine, supply the machine name as the sole parameter, e.g., fixrasi \\machine1.

How can I tell if the tool completed correctly?
The tool will print a text message to the console that says whether it successfully eliminated the vulnerability. If the tools fails, it will provide an error message explaining what the cause of failure was.
The tool also will provide a return code for use in deploying it via SMS or batch files. The tool will provide a return code of 0 if it successfully completed, or 1 if it encountered an error.

What is Microsoft doing about this issue?

  • Microsoft has developed 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 patch.
  • 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 patch in more detail.

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

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

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.