Microsoft Security Bulletin (MS00-006): Frequently Asked Questions
What's this bulletin about?
Microsoft Security Bulletin MS00-006 announces the availability of a patch that eliminates two vulnerabilities in Microsoft® Index Server. The first vulnerability could allow a malicious user to read files on the web server under certain conditions; the second could reveal where web files are located 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 was the bulletin re-released?
The bulletin was re-released on March 31, 2000, to advise Windows NT 4.0 customers of a new variant of one of the vulnerabilities, which will require them to apply a new version of the patch. The new variant does not affect Indexing Services on Windows 2000, so customers who previously applied the patch to Windows 2000 systems do not need to take any further action.
What's the scope of the vulnerabilities?
The first vulnerability could allow a malicious user to view files that reside on a web server. It would not allow him or her to change, delete or add files. This vulnerability affects only files that reside on the web server itself, and only on the same logical drive as the server's root directory. Files residing on a remote server at a web site - for instance, files on a remote database server - would not be at risk from this vulnerability.
The second vulnerability could reveal the physical location of web directories on the server. It would not allow a malicious user to read, create, change or delete files on the server. However, it could be useful as a reconnaissance tool - for instance, a malicious user could use this vulnerability to determine the location of interesting files on the server, then use the above vulnerability to retrieve them.
What do these vulnerabilities have in common?
These vulnerabilities are unrelated to each other except for the fact that both occur in Index Server. They have been combined in the same patch for customer convenience.
What is Index Server?
Index Server is a search engine that is integrated with Internet Information Server and Windows NT. It allows users to perform full-text searches of online sites using their browsers. Unlike many other search engines, Index Server can search Word, Excel and PowerPoint documents as well as HTML documents.
Two versions of Index Server are affected by these vulnerabilities. Index Server 2.0 is a stand-alone server product that was shipped as part of the Windows NT 4.0 Option Pack. In Windows 2000, Index Server was incorporated as a system service known as Indexing Services. For simplicity, we have referred to the product as Index Server throughout this bulletin.
Is Index Server installed and running by default?
No. In Windows NT 4.0, Index Server is provided as part of the Windows NT 4.0 Option Pack. Even if installed, Index Server does not run unless explicitly enabled. In Windows 2000, Indexing Services is installed by default, but the service is not started unless the administrator explicitly starts it.
What are the vulnerabilities?
The first vulnerability is the "Malformed Hit-Highlighting Argument" vulnerability. The second hasn't been given a name, as it only involves a single error message that provides inappropriate information.
Do both vulnerabilities affect Indexing Services in Windows 2000?
No. Only the "Malformed Hit Highlighting" vulnerability affects Indexing Services in Windows 2000. The second vulnerability only affects Index Server in Windows NT 4.0.
What is the "Malformed Hit-Highlighting Argument" vulnerability and why does it occur?
This vulnerability occurs because the "Hit-Highlighting" function of Index Server (also known as the "Webhits" function) doesn't correctly constrain what a user can request. If provided a specific type of malformed request, it will retrieve files on the server, regardless of the permissions that have been set by the administrator. There are some limitations on what files can be retrieved, and these are discussed in detail below.
What is the Hit-Highlighting feature?
When you search a document with Index Server, the Hit-Highlighting feature shows the exact portions of the document that satisfy your query. It generates an HTML page containing a list of the matches, with those words making up the hit highlighted. Each hit is displayed together with some of the text that surrounds it in the document. Also, for each document in which a hit is found, Index Server gives you a link to the full text of that document.
What's the problem with the Hit-Highlighting feature?
By design, the Hit-highlighting feature allows the user to specify the name of the document to be hit-highlighted. The user should only be able to request documents within the server's virtual directories, for example, www.microsoft.com/security/document.doc. However, if a specific type of malformed argument is provided, it can be used to request a file by its physical location on the drive, for example c:\folder\document.doc.
Why is this a security problem?
Not all of the files on a web server are intended to be viewed by visitors to the site. For instance, system configuration files, usage logs and other files should only be viewed by the server administrator. One purpose of virtual directories is to clearly separate what is intended for visitors' use and what is not. By allowing users to search files that are outside of the virtual directories, this vulnerability enables malicious users to request bogus searches of files on the server, simply as a way of viewing them.
Are there any limitations on what files could be viewed?
Yes. There are two significant limitations on what files could be viewed via this vulnerability.
| • | Only files on the server itself could be viewed. For instance, if a web server worked in conjunction with a database server, this vulnerability would not allow a malicious user to request files from the database server. |
| • | Only files on the same logical drive as the web root directory could be viewed. For instance, if the web server's hard drive were partitioned into a C: and D: drive, and the server's virtual root were located on the D: drive, this vulnerability would only allow files from the D: drive to be retrieved. |
Would this vulnerability allow files to be changed?
No. The files could be read, but not changed. Likewise, files couldn't be deleted from or added to the server.
Could this vulnerability be exploited accidentally?
No. The malformed argument at issue here is extremely unlikely to be accidentally entered.
What is the new variant of this vulnerability that was announced on March 31, 2000?
After releasing the original patch, we learned of an additional variant of this vulnerability that affects only Windows NT 4.0. Through this variant, a malicious user could continue to read certain types of files even after the original version of the patch was applied. Specifically, it would allow him to specify a server-side web file as a document to be hit-highlighted. This would allow the malicious user to view the source code of such a file.
What is a server-side file, and why is it a security vulnerability for someone to be able to view its source code?
"Server-side" files are ones that are intended to be processed on the server, but never sent to the user. An example is an .ASP file - an .ASP file is used to generate a web page that will be sent to the user, but should never be sent itself.
The ability to read server-side files is a security vulnerability because web developers sometimes include sensitive information in them. However, recommended security practices militate against doing this, and if this guidance were followed, there would be no sensitive information in such files to compromise.
What is the second vulnerability addressed by this patch, and why does it occur?
The second vulnerability occurs because of a faulty error message that Index Server returns when a non-existent Internet Data Query file is requested. The error message should refer to the requested file in the same terms that it was requested; for example, if the user requested www.microsoft.com/xyz/query.idq, the error message should return "www.microsoft.com/xyz/query.idq not found". Instead, it refers to the file by its physical location, for example, "c:\webroot\xyz\query.idq not found". This would allow the requester to infer that the "xyz" virtual directory maps to c:\webroot\xyz.
Does this vulnerability affect Indexing Services in Windows 2000?
No. This vulnerability only affects Index Server in Windows NT 4.0.
What is an Internet Data Query file?
An Internet Data Query (.IDQ) file defines query parameters for an Index Server search, and can contain information like the scope of the search, search restrictions, and query result sets. Typically, a search involving an .IDQ file also will include two other files, one that creates the query, (an .htm file) and one that formats the search results, (an .htx ile).
Why is this a security vulnerability?
By itself, this is not a security vulnerability. It doesn't enable a malicious user to change data or usurp control over the machine. However, it would be a useful reconnaissance tool for a malicious user who wanted to know where interesting files were located on the server. For instance, a malicious user might first use this vulnerability to learn where .ASP pages were stored on the server, then use the "Malformed Hit-Highlighting Argument" vulnerability to retrieve the pages' source code.
Could this vulnerability be exploited accidentally?
Yes. The error message that's at fault here is generated anytime a user requests an Internet Data Query file that doesn't exist. This could happen as a result of a typographical error or other innocent mistake. However, repeated requests for non-existent .IDQ files could indicate that a malicious user is systematically trying virtual directory names in order to map the server.
What is the new variant of this vulnerability that was announced on February 04, 2000?
Shortly after the initial posting of this bulletin and the patch, an additional variant of this vulnerability was reported. This variant was eliminated by the original patch, so customers who applied the original patch do not need to apply a new one.
The new variant provides an additional way to read files from the server. An IDQ file always specifies the .HTX file that should be used to format the search results. However, under certain conditions, it was possible to request an arbitrary file. As in the case of the "Malformed Hit-Highlighting Argument" vulnerability, this vulnerability would only allow files on the server, and on the same logical drive as the web root, to be read. It would not allow them to be changed in any way.
Does the new variant affect Indexing Services in Windows 2000?
No.
Should I take any other action with regard to the new variant?
Yes. The patch eliminates the vulnerability in Index Server, but there is an additional aspect to this vulnerability that is worth noting. If a web site developer creates an .IDQ file but does not constrain user inputs so that only .HTX files can be chosen for formatting the output, it would be possible for the user to specify any desired file as the output formatter, and thereby read the file. In particular, one of the sample files provided with Index Server, prxrch.idq, does not constrain user inputs adequately. Like all sample files, this one should not be present on a production server.
I am hosting a web site on Windows NT 4.0 and using Index Server 2.0 to provide search services. Should I apply the patch?
Yes.
I am hosting a web site on Windows 2000 and using Indexing Services to provide search services. Should I apply the patch?
Yes.
I am hosting a web site, but not providing search services. Should I apply the patch?
There are two approaches that you can take:
| • | You can apply the patch. The advantage of this approach is that if you decide to provide search services of your site at some future point, you'll be protected against the vulnerability. |
| • | You can remove the script mapping for the affected file types. In the Internet Service Manager, remove the script mappings for .HTW, .IDQ, and .IDA files. This will prevent either of the components affected by the vulnerabilities from being invoked. |
What does the patch do?
The patch eliminates the "Malformed Hit-Highlighting Argument" vulnerability by preventing the specific malformed argument from being processed. It prevents the second vulnerability by changing the error message so that it refers to the requested file in terms of its virtual directory rather than its physical location.
Where can I get the patch?
The download location for the patch is provided in the "Patch Availability" section of the security bulletin.
There have been several new releases of this patch. How can I tell if I need to re-apply it?
Windows 2000 users:
| • | If you applied the original patch, you do not need to apply a new version. The original version eliminates all known variants of the vulnerabilities. |
| • | You may choose to install the version of the patch released on February 11, 2000, in order to install the new Windows 2000 hotfix tool. |
Windows NT 4.0 users:
| • | If you applied the original patch, you should apply the new version that was released on March 31, 2000. It eliminates all known variants of the vulnerabilities. |
How can I tell if I installed the patch correctly?
Knowledge Base article 251170 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 vulnerabilities. |
| • | Microsoft has provided a security bulletin and this FAQ to provide customers with a detailed understanding of the vulnerabilities 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 251170 and 252463 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 step-by-step checklist for securing an IIS web server 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.
