What's the scope of the vulnerability?
This vulnerability is a new variant of the "File Fragment Reading via .HTR" vulnerability discussed in Microsoft Security Bulletins MS00-031 and MS00-044. The scope of the new variant is exactly the same as that of the previous ones: it could enable an attacker to read certain parts of certain files on a web server. However, as in the original version of the vulnerability, the vulnerability would not enable the attacker to add, change or delete files.
Microsoft has long recommended removing the file mapping for HTR files, and customers who have done this would not be at risk from this vulnerability. Microsoft recommends that, as a first choice, customers disable the HTR functionality altogether; only customers who have a compelling reason to retain the HTR functionality should retain the functionality and apply this patch.
What causes the vulnerability?
The vulnerability results because it's possible to request a file from the server in a way that causes it to be processed by the ISAPI extension for .HTR files. This could cause portions of the file's contents to be sent to the requester.
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. Such code can be implemented in either of two forms:
- As an ISAPI filter, if the new functionality provides a low-level service.
- As an ISAPI extension, if the new functionality provides a high-level service.
In the case of this vulnerability, the affected code is an ISAPI extension. Specifically, it's the ISAPI extension that processes .HTR files.
What is .HTR?
HTR is a first-generation advanced scripting technology delivered as part of IIS 2.0. HTR was never widely adopted, largely because a far superior technology, Active Server Pages (.ASP), was introduced in IIS 4.0 and became popular before customers had invested significant development resources in HTR.
The widest present-day use of the HTR technology is in a collection of HTR scripts included by default in IIS; these enable IIS to provide Windows NT password services via IIS web servers. Windows NT users can use the .HTR scripts to change their own passwords, and administrators can use them to perform a wide array of password administration functions. More information on these scripts is available in Knowledge Base article Q184619.
What would this vulnerability allow an attacker to do?
If an attacker requested a file using a specific type of malformed URL, it would be possible to cause IIS to use the .HTR ISAPI extension to process non-.HTR files. The result of doing this would vary from file type to file type. However, in the file type of greatest interest here -- .ASP files - fragments of the file contents could be sent to the attacker.
Why would this pose a security risk?
.ASP files are the best example of a server-side file type, so called because they're intended to be processed on the server, rather than on the web client. When a web client requests an .ASP file, it's processed on the server (by an ISAPI extension) and the results - not the source code - should be sent to the requester. This vulnerability poses a security risk because, by enabling an attacker to obtain fragments of .ASP source code, it's possible that the attacker could harvest sensitive data from them.
However, it's important to note that, for reasons beyond this vulnerability, sensitive data should never be contained in .ASP files. If this recommendation has been followed, there would be no sensitive data to be divulged, even if an attacker did exploit the vulnerability. Even in the case where best practices had not been followed, and .ASP files did contain sensitive data, it's unlikely that this vulnerability would actually divulge it, as the .HTR processing would tend to remove the very content that would be of most interest to the attacker.
Why would the .HTR processing tend to remove sensitive content?
The .HTR processing would have the effect of removing everything but text from a file. Typically, sensitive information would be encoded as program code rather than text, and the .HTR processing would interpret the code rather than passing it to the attacker. For instance, if this vulnerability were used to try to read a file whose contents were:
<b>Some HTML code</b>
<%
/*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 code</b>
<I>other html code</I>
other code.
The HTML code that would be sent to the attacker is exactly the same information that would normally be sent after the .ASP file had been processed, so the attacker wouldn't learn anything he couldn't learn by levying a normal and legitimate request for the page. The part of the file that would be most likely to contain sensitive information -- the .ASP code -- would be stripped out by the .HTR processing.
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.
Would the vulnerability enable the attacker to read files regardless of the permissions on them?
No. The vulnerability does not provide a means of bypassing the file permissions. The attacker would need to have execute permission on any file that he wanted to try to read via this vulnerability.
What should customers do about this vulnerability?
Customers who do not have a business-critical reason why they must use the .HTR functionality should disable it. Customers who disable the functionality now would not need to apply any of the previously-released patches involving the HTR functionality, nor would they need to apply the patch provided here, nor any future ones. Customers who must use the .HTR functionality should apply the patch discussed below.
How do I disable the HTR functionality?
Just follow these steps:
- Open the Internet Services Manager
- Right-click the web server, then choose Properties, then Master Properties, then WWW Service.
- Choose Edit, then HomeDirectory, then Configuration
- Remove the .HTR entry
It's worth noting that, in addition to .HTR, Microsoft also recommends removing several other so-called script mappings. These are discussed in the IIS 4.0 Security Checklist.
Who should use the patch?
Microsoft recommends that only customers who have a business-critical reason to continue using .HTR install the patch. All other IIS users should remove the .HTR functionality instead.
What does the patch do?
The patch eliminates the vulnerability by causing the request at issue here to be handled by the proper ISAPI extension. In addition, it eliminates the vulnerabilities discussed in Microsoft Security Bulletins MS00-031 and MS00-044.
So, if I apply this patch, I don't need to apply the patches provided in Microsoft Security Bulletins MS00-031 and MS00-044?
That's correct. However, the best way to eliminate all of these vulnerabilities is to disable .HTR. If you do that, you won't ever have to apply a patch related to .HTR again.
