Microsoft Security Bulletin (MS00-019): Frequently Asked Questions
What's this bulletin about?
Microsoft Security Bulletin MS00-019 announces the availability of a patch that eliminates a vulnerability in Microsoft® Internet Information Services and several products that run atop it. The vulnerability could cause a web server to send the source code of a web file to a visiting user, under unusual conditions. 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.
What's the scope of the vulnerability?
The vulnerability could cause the source code of certain types of files to be sent from a web server 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 under very specific, and fairly unusual, conditions. The file must reside on a different machine from the web server, and the visitor must malform the request by adding certain invalid characters to the end of it. Many web browsers automatically remove or change these characters before sending the request to the server, making it even less likely that this vulnerability would occur at random.
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 scripting engine, that processes files of that type. There is one scripting engine for .ASP files, one for .HTR files, and so forth. File types that don't have an associated scripting engine (.HTM files, for instance) are simply sent to the browser.
When a browser requests a file from a web server, IIS determines what scripting engine to invoke by checking the file extension. However, if the file resides on a UNC share, and the user appends one of several particular characters to the end of the request, IIS will locate the correct file but not recognize it as a file that needs to be processed by a scripting engine. Instead, it will simply send the file to the browser.
What's the risk in sending source code of web files to the browser?
For many types of files, there's no risk. .HTM files, for instance, are designed to be sent in their entirety to the browser. However, .ASP and other advanced file types are intended to never leave the server - only the output of the file, when processed by the scripting engine, should be sent to the browser.
The reason is that 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.
If recommended security practices had been followed, and the .ASP code didn't contain any sensitive information, what would the risk be from this vulnerability?
There would be little or no risk.
What's a UNC share?
UNC stands for Universal Naming Convention. It's the naming convention that's used to allow directories and files to be shared over a network, and is supported by all Microsoft networking products. Suppose the owner of Machine1 wanted to allow other users to access files in the directory C:\Data. He would create a share and give it a name. For this example, let's assume that he called the share Myshare. Once he had done this, authorized users and machines could access the C:\Data directory on Machine1 by using the UNC nomenclature, \\Machine1\Myshare.
What do UNC shares have to do with this vulnerability?
The vulnerability only occurs when a requested file is accessed via a UNC share. That is, the vulnerability only exists if the file that's requested doesn't reside on the web server, but instead resides on another machine that the web server accesses via a UNC share. This is a very significant point, because it means that servers that only serve files from their local storage are not affected by this vulnerability.
Why would the files be on a separate machine from the server?
The best way to explain is by example. Suppose you operated a web site, and you had chosen to deploy several web server machines in order to ensure high availability. You might put the web files on a separate machine that all of the web servers would access.
How could a user tell which files are accessed by UNC shares?
Under normal conditions, they would be unable to tell. Web server software deliberately makes it appear that all data resides on the server, by using so-called virtual directories. For example, when you request a page from www.microsoft.com/security, the "security" virtual directory may contain files that all reside on one server or are distributed across many. This is done primarily to simplify the user experience, but it also has the effect of making it more difficult to exploit this vulnerability.
Does this vulnerability occur whenever a user requests a file residing on a UNC share?
No. There are two parts to the vulnerability:
| • | The file must reside on a UNC share |
| • | The must append a special character to the end of the request for the file. The characters at issue here would normally make the request invalid, and as a result, many browser will remove the characters or replace them with more appropriate ones. Thus, on some browsers, it would impossible to exploit this vulnerability |
Could this occur accidentally?
It's very unlikely that anyone would exploit this vulnerability by accident.
Who should apply the patch?
Customers should apply this patch if they are using one of the affected products to serve .ASP and other advanced files residing on remote machines.
What does the patch do?
The patch eliminates the vulnerability by removing the trailing special characters if they are included on the request. This causes the appropriate scripting engine to process the file when it's served to the browser.
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?
The KB article provides a manifest of the files in the patch package. The easiest way to verify that you've installed the patch correctly is to verify 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 a Knowledge Base article explaining the vulnerability and patch in more detail. |
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. A security checklist for IIS 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.
