Security TechCenter > Security Bulletins > Microsoft Security Bulletin (MS99-058): Frequently Asked Questions

Microsoft Security Bulletin (MS99-058): Frequently Asked Questions

What's this bulletin about?
Microsoft Security Bulletin MS99-058 announces the availability of a patch that eliminates a vulnerability in Microsoft® Internet Information Server (IIS), as well as other Microsoft products that run atop IIS. The vulnerability could, under certain circumstances, cause the source code of web pages to be sent to a visiting user. 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?
The vulnerability could cause the source code of certain types of web server files to be sent to a visiting user's browser. It would not enable a malicious user to change the files on a server or take any other administrative action on it.
The vulnerability only occurs if a file resides in a virtual directory with a specific, and fairly uncommon, type of name. By default, web site visitors cannot change virtual directory names and in this case, this would pose at best a target of opportunity for a malicious user. Most commonly, this vulnerability would occur because of an administrative error or because an affected virtual directory name had been chosen by default by software running on the web server.

What causes the vulnerability?
IIS supports advanced file types such as .ASP and .HTR files. These significantly improve the power and flexibility of web hosting services. In contrast to static web content like .HTM files, these advanced file types can be thought of as programs that, when requested, are executed on the server via so-called server-side processing. Every advanced file type has an interpreter, also known as a filter, that processes files of that type. There is one filter for .ASP files, one for .HTR files, and so forth. File types that don't have an associated filter (.HTM files, for instance) are simply sent to the browser.
When a browser requests a file from a web server, IIS determines what filter to invoke by checking the file extension. However, due to a flaw in the algorithm that parses these requests, if a valid file extension is contained in a virtual directory name, IIS will sometimes perform the wrong processing. In most cases, this causes an error but poses no security risk. However, in some cases, it can cause the source code of the file to be sent to the browser. For instance, if the file //server/directoryname.com/file.asp were requested, IIS would see the ".com" in the virtual directory name and conclude that file.asp was actually a .com file. Because there is not a filter for .com files, IIS would simply send file.asp to the browser.

What's the risk in sending source code of .ASP files to the browser?
Web content developers sometimes include sensitive information in .ASP and other advanced file types. For instance, they sometimes include information such as passwords in the files in order to personalize the content that they generate. This is contrary to recommended practices, and secure methods of storing and using such information are available; nevertheless, it is a frequent error. If such a web file were sent directly to a browser, it could compromise any sensitive information it contained.

Wouldn't I see the error when I tested my web site?
Yes. If you had created a directory with an affected name, testing would quickly show that the web content was not being served correctly.

I think I previously saw a Knowledge Base article on this subject. Was it previously known?
Yes. Microsoft Knowledge Base article 186803 previously discussed this issue and recommended a workaround, namely, that web administrators avoid including file extensions in virtual directory names. We decided to develop a patch and release a security bulletin in order to simply eliminate the vulnerability altogether.

Would the vulnerability always cause a file's source code to be sent to the browser?
No. The exact effect of the vulnerability would vary, depending on the file extension that was included in the directory name and the particular type of file that was requested. For example, if ".htr" were included in a directory name, and an .ASP file were requested, IIS would attempt to process the .ASP file using the .HTR filter, and this operation would fail. In most cases where this vulnerability occurs, the result is that the operation fails and returns an error. However, the worse case is one such as discussed above, that results in the server sending a file's source code to the browser.

How would an affected directory name be created?
By default, only a web site administrator can create a virtual directory, so this vulnerability would most likely happen as a result of administrator action. However, there also are programs that create virtual directories with affected names; one of these is Front Page Server Extensions. However, even in the case of Front Page Server Extensions, the product only creates the affected directories. It doesn't put any web files in any of the directories.

Could a malicious user cause this vulnerability to occur?
Only if he or she had been given permission to create or change virtual directory names. This is not permitted by default, and is not a recommended practice.

Will this vulnerability affect the version of IIS in Windows 2000?
No.

What does the patch do?
The patch changes how IIS parses virtual directory names. If a directory name contains a file extension, IIS will return an error anytime a file from that directory is requested.

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

How can I tell if I installed the patch correctly?
Knowledge Base article 238606 provides a manifest of the files in the patch package. The easiest way to verify that you've installed the patch correctly is to check that these files are present on your computer, and have the same sizes and creation dates as shown in the KB article.

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 Knowledge Base articles 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. A comprehensive checklist for securing IIS servers is available at http://www.microsoft.com/technet/security/chklist/iischk.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.