Microsoft Security Bulletin (MS00-031): Frequently Asked Questions
What's this bulletin about?
Microsoft Security Bulletin MS00-031 announces the availability of a patch that eliminates two vulnerability in Microsoft® Internet Information 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.
What's the scope of the vulnerabilities?
There are two vulnerabilities here. The first, the "Undelimited .HTR Request" vulnerability, is a denial of service vulnerability that could be used to prevent an affected web server from providing useful service. The second, the "File Fragment Reading via .HTR" vulnerability could allow certain types of files to be read from the server under very unusual conditions.
Neither of these vulnerabilities would allow data to be changed, added or deleted on the server, nor would either allow administrative control over the machine to be usurped. If security recommendations have been followed, many customers will have disabled the functionality affected by the vulnerabilities; customers who have done this are not affected by the vulnerabilities.
How are these vulnerabilities related to each other?
They are only related in the sense that both lie in the same ISAPI extension, ISM.DLL, and involve the processing of .HTR files.
What is an ISAPI extension?
ISAPI (Internet Services Application Programming Interface) is a technology that enables web developers to extend the functionality of their web servers by writing custom code that provides new services for a web server. The custom code can either be implemented in an ISAPI filter, if the new functionality provides a low-level service, or an ISAPI extension, if the new functionality provides a high-level service. In this case, the affected code is an ISAPI extension.
What is a script mapping?
After a developer writes an ISAPI extension, web developers can use the functionality it exposes. However, there needs to be a way for IIS to know which ISAPI extension should be used to process a particular file. It does this via script mappings - a mapping of a particular file extension to its associated ISAPI extension.
For example, Advanced Server Page (ASP) technology is implemented as an ISAPI extension in IIS. There is a default script mapping that associates the file extension .asp with this ISAPI extension. So, when a web developer hosts an .asp file on his web site and a user requests it, the script mapping allows IIS to know that it needs to process the file using the ASP ISAPI extension.
What are .HTR files?
.HTR files are scripts that allow Windows NT password services to be provided via IIS web servers. Windows NT users can use .HTR scripts to change their own passwords, and administrators can use them to perform a wide array of password administration functions. More information on this functionality is available in Knowledge Base article 184619
It's worth mentioning that, as a general practice, it's always a good idea to remove any unneeded script mappings, and .HTR files are no exception. As discussed in the IIS 4.0 Security Checklist, unless web-based password management features are needed, the script mapping for these files should be removed. If this has been done, none of the vulnerabilities described in this bulletin can affect the server.
Do either of these vulnerabilities jeopardize passwords?
No. They just happen to occur in the functionality that provides web-based password administration services. Neither vulnerability exposes passwords or weakens them in any way.
What is the "Undelimited .HTR Request" vulnerability?
The first vulnerability is a denial of service vulnerability. All .HTR files accept certain parameters that are expected to be delimited in a particular way. This vulnerability exists because the search routine for the delimiter isn't properly bounded. Thus, if a malicious user provided a request without the expected delimiter, the ISAPI filter that processes it would search forever for the delimiter and never find it.
If a malicious user submitted a password change request that lacked an expected delimiter, ISM.DLL, the ISAPI extension that processes .HTR files, would search endlessly for it. This would prevent the server from servicing any more password change requests. In addition, the search would consume CPU time, so the overall response of the server might be slowed.
How could an affected server be put back in service?
An affected server could be put back in service by stopping and restarting the IIS service.
Could this vulnerability be exploited accidentally?
It's possible but unlikely. Password change requests are usually submitted using HTML forms rather than by directly invoking the ISAPI filter. All of the default HTML forms for this purpose that are provided with IIS 4.0 and 5.0 check for the missing delimiter and will not forward a request in which it is missing.
What is the "File Fragment Reading via .HTR" vulnerability?
This vulnerability could allow a malicious user to read certain types of files under some very restrictive circumstances by levying a bogus .HTR request.
Why would a bogus .HTR request let a malicious user read files?
The specific format of the bogus request at issue here causes the target file on the server to be processed as though it were an .HTR file. When this happens, some of the contents could be returned to the user.
What do you mean by "some of the content" could be returned?
The ISAPI filter will attempt to interpret the requested file as an .HTR file, and this would have the effect of removing virtually everything but text from a selected file. That is, it would have the effect of stripping out the very information that is most likely to contain sensitive information in .asp and other server-side files.
For instance, if this vulnerability were used to try to read a file whose contents were:
<b>Some HTML text</b>
<%
/*Some <file://Some/> ASP/HTR code*/
var objConn = new ActiveXObject("Foo.bar");
%>
<I>other html code</I>
other code.
The information that would be returned to the malicious user would be:
<b>Some HTML text</b> <I>other html code</I> other code.
What other restrictions are there on this vulnerability?
In order to exploit this vulnerability, there would need to be zeros in fortuitous memory locations on the server. Specifically, IIS performs some initial processing of an .HTR request, then places part of the request into a temporary location for additional processing. In order to exploit this vulnerability, a zero would need to already reside in exactly the right place to null-terminate the string that is placed there.
There are two ways a malicious user might try to overcome this restriction. The first would be to repeatedly levy requests in the hope of getting lucky. The alternative would be to wait until immediately after the server had been rebooted. The server memory is zeroed as part of the initialization process, so a zero would be guaranteed to be in the right place; however, the server memory would quickly become "dirtied" by use, so the window of vulnerability would be quite short.
What does the patch do?
The patch eliminates the first vulnerability by limiting how far the algorithm will search for an expected delimiter. It eliminates the second by causing ISM.DLL to reject the type of bogus request that allows the file data to be read.
How do I use the patch?
The Knowledge Base articles contains detailed instructions for applying the patch to your site.
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 articles 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 either 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 two Knowledge Base articles 260838,260069 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. In particular, a security checklist for IIS 4.0 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.
