Microsoft Security Bulletin (MS00-025): Frequently Asked Questions

What's this bulletin about?
Microsoft Security Bulletin MS00-025 discusses a procedure that eliminates a vulnerability in Microsoft® Visual Interdev 1.0, affecting customers who use several web server products. A component of Visual Interdev 1.0 that ships with these products could, under certain conditions, allow a malicious user to cause an affected web server to crash or run code of his choice on the server. Microsoft is committed to protecting customers' information, and is providing the bulletin to inform customers of the vulnerability and what they can do about it.

Why has Microsoft updated this bulletin so many times?
Common sense, and common industry practice, recommend that when a person believes he has found a security vulnerability in a vendor's product, he should report it to the vendor and give the vendor a decent interval in which to verify whether there is a problem or not. Unfortunately, in this case, this was not done. Both the original vulnerability and the new one were made public before Microsoft had an opportunity to investigate them.
In both cases, the initial reports wildly overstated the scope of the vulnerability. Because the claims received widespread attention and generated significant customer concern, Microsoft has had to report interim findings and continually update the bulletin as we learn more. We believe that the current update is the last one that will be needed.

What's the scope of the vulnerability?
This is a buffer overrun vulnerability. A malicious user with privileges that allow him to use a particular server component could use this vulnerability to cause a web server to crash, or to run code of his choice on the server. It is important to note that, under default conditions, normal users could not access the affected component, and therefore could not exploit the vulnerability.
Although there have been several updates to this bulletin, the remediation steps have always been the same - customers using the affected products on web servers should delete the component at issue in the vulnerability. Customers who already have done that do not need to take any additional action to protect themselves from the immediate vulnerability. However, as a matter of best practices, Microsoft recommends that all customers review the permissions on the folders where FPSE authoring programs are stored in order to prevent potential future abuse of these programs by unauthorized persons.

What causes the vulnerability?
A server-side component, Dvwssr.dll, is provided as part of several web server products to support the Link View feature in Visual Interdev 1.0. This component contains an unchecked buffer that could be exploited via a buffer overrun attack.

What is Visual Interdev?
Visual Interdev is a development environment for designing, building, and debugging data-driven Web applications. Visual Interdev 1.0 was released in 1995.

What is the Link View feature in Visual Interdev, and what does it do?
When building a web site, it's helpful to be able to see graphically how the various pages relate to each other; for instance, which pages provide links to which other pages. Link View allows a web author to generate and view such a "map" of the web site.

What is the problem with the Link View feature in Visual Interdev 1.0?
To generate the Link View information, there must be components on both the client and server sides: the client side to request information from the server and build the view, and the server side to provide information about the web pages. The vulnerability lies in the server-side component, Dvwssr.dll, which is vulnerable to a buffer overrun attack.

What could someone do via a buffer overrun?
Buffer overruns can be exploited in two ways. The simplest allows denial of service attacks. By providing a malformed argument as part of a service request made to the affected component, a malicious user could crash the web server. A more esoteric attack would involve overwriting the buffer with specially-chosen data, in order to cause the server to run code of the malicious user's choice.

Who could exploit this vulnerability?
Under default conditions, Dvwssr.dll resides in the folder _vti_bin/_vti_aut, whose permissions only allow web authors to execute it. If the permissions are left at the default settings, only a person with web authoring privileges on the server could exploit the vulnerability. Normal users could only exploit this vulnerability if the default permissions were changed, or Dvwssr.ddl had been copied to a folder with lower permissions.

What would this vulnerability allow web authors to do that they couldn't do before?
Very little. Web authors are privileged users who have the ability to upload and execute content on the server, including installing components that will run in a System context. Such users already have the ability to interfere with the operation of the server, or to run arbitrary code on it. This is one reason why web authorship privileges should only be granted to trusted users.
In the hands of a malicious web author, this vulnerability would provide only one additional capability. Normally, all actions taken by a web author are subject to auditing. However, this vulnerability would allow normal auditing functions to be bypassed. As a result, ISPs that provide web hosting services should remove Dvwssr.dll.

If the defaults had been changed, and normal users could exploit the vulnerability, what could they do?
If normal users could execute Dvwsr.dll, the vulnerability would pose a serious risk to safe operation. It would allow a visitor to an affected web site to crash the server or potentially run code of his choice on the machine in a System context.

What would need to happen for a normal user to exploit this vulnerability?
The key is whether web site visitors have execute permissions to Dvwssr.dll. By default, they do not, and therefore could not exploit this vulnerability. However, if the permissions were changed to allow normal users to execute it, they could exploit the vulnerability.

What are the correct permissions for the folder where Dvwssr.dll is stored?
Dvwssr.dll is normally stored in the folder_vti_bin/_vti_aut. By default, the permissions on this folder are set as follows:

It is important that these permissions not be reduced. Likewise, if Dvwssr.dll (or any of the FrontPage Server Extension authoring .dlls that normally reside in the same folder) are moved to another folder, it is important that the new folder have equivalent protections.

My web server is using a FAT file system, so I can't set permissions on individual folders. What should I do?
It is never appropriate for a Windows NT® web server to use a FAT file system. Customers who are using FAT file systems should convert them to NTFS immediately, then reinstall all web server software to ensure that the folder permissions are correctly set. FAT volumes are inappropriate because, completely unrelated to this particular vulnerability, they do not allow permissions to be set on a file-by-file or folder-by-folder basis. Any user who can access such a server has, by definition, full control over all folders and all files on it. If you have a Windows NT web server with a FAT system, and the administration tools are present on the system, anyone who can connect to your server can administer it.
For Windows® 95 and 98 servers, the situation is slightly different. These systems must use a FAT file system, so Personal Web Server 4.0, the web server software that ships with these systems, does not allow remote administration of any kind.

What should customers do about this vulnerability?
Microsoft recommends that all customers using the affected products to run web servers verify that this component cannot be executed by normal users. Better still, delete the file altogether to eliminate any possibility of risk. As discussed below, the component is only needed if Visual Interdev 1.0 is used to manage the web server, so the vast majority of customers can delete it with no loss of functionality.

The original version of this bulletin discussed a file access vulnerability in this component. Why aren't you discussing it anymore?
The scope of the buffer overrun vulnerability far exceeds that of the file access vulnerability that originally was reported. The original vulnerability allowed certain users to view files on the server; the buffer overrun vulnerability potentially could allow a malicious user to perform any desired action on the server, including viewing the same files. We have therefore modified the bulletin to discuss only the buffer overrun vulnerability.

I heard that Dvwssr.dll provides a "back door" into a web site. Is this true?
No. A "back door" is a means by which a user who knows a password or some other secret information can bypass access control checking. Dvwssr.dll does not provide a way to do this.

But wasn't a password of some kind needed to exploit the original vulnerability?
Press reports originally claimed that Dvwssr.dll used a password to bypass access controls, but this was not correct. The component uses an obfuscation key to obscure the names of files being requested by the client while the request is in transit to the server. The obfuscation key and its use did not influence the operation of the access controls on the server in any way.

What machines are primarily at risk from this vulnerability?
The following products install Dvwssr.dll, and web servers using any of them could be vulnerable:

I'm using Windows 95 and/or Windows 98. Could I be affected by this vulnerability?
If you are not hosting a web site on your Windows 95/98 system, this vulnerability could not affect you. Even if are hosting a web site, this vulnerability poses little threat. As mentioned above, Personal Web Server 4.0, the web server software that ships as part of Windows 95 and 98, does not allow any remote administration of web sites, and so a visitor to your site could not call Dvwssr.dll. A user who has physical access to your web server could use Dvwssr.dll and exploit the vulnerability, but, by definition, such a user would already have complete control of your machine already, and the vulnerability would offer him no additional capabilities.

I'm using Windows NT 4.0. Could I be affected by this vulnerability?
You could only be affected by this vulnerability if either of the following is true:

I'm using Windows 2000. Could I be affected by the vulnerability?
No. Windows 2000 does not include the affected component, nor does IIS 5.0, the web service included as part of Windows 2000.

I was running IIS 4.0 on Windows NT 4.0, but I upgraded to Windows 2000. Could I be affected by the vulnerability?
No. The upgrade process deactivates Dvwssr.dll.

I'm running Office 2000 Server Extensions. Could I be affected by the vulnerability?
No. Office 2000 Server Extensions deactivates Dvwssr.dll.

I'm running FrontPage 2000 Server Extensions. Could I be affected by the vulnerability?
No. FrontPage 2000 Server Extensions deactivates Dvwssr.dll.

I have the affected component. What should I do?
One way to eliminate the problem is to install Windows 2000, Office 2000 Server Extensions, or FrontPage 2000 Server Extensions. All three of these products deactivate the affected component as part of the installation process.
Alternatively, you can erase the file Dvwssr.dll from your server. Here's how:

I deleted Dvwssr.dll when the original version of the bulletin was released. Do I need to take any other action?
No. If you have already deleted the file, you cannot be affected by the vulnerability.

Will I lose any functionality if I erase dvwssr.dll?
The loss of functionality is minimal. Dvwssr.dll serves only one purpose, to help Visual Interdev 1.0 clients generate link views. After deleting the file, you would be unable to view Links from .asp pages in the Visual Interdev 1.0 Link View feature. No other products, including subsequent versions of Visual Interdev, would be affected by deleting this file.

What is Microsoft doing about this issue?

Where can I learn more about best practices for security?
The Microsoft TechNet Security web site is the best to place to get information about Microsoft security. In particular, the web site provides a security checklist for IIS 4.0 available at http://www.microsoft.com/technet/security/chklist/default.mspx and a security lockdown tool for IIS 5.0, available at http://www.microsoft.com/technet/security/tools/default.mspx.

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.

Top of page