Microsoft Security Bulletin MS01-004 - Important

Malformed .HTR Request Allows Reading of File Fragments

Published: January 29, 2001 | Updated: November 04, 2003

Version: 1.1

Originally posted: January 29, 2001
Updated: November 04, 2003

Summary

Who should read this bulletin:
System administrators who host IIS web servers and have not previously disabled .HTR mapping.

Impact of vulnerability:
Information disclosure

Recommendation:
Disable .HTR mapping as a first resort; apply the patch only if there is a business-critical reason for retaining .HTR functionality.

Affected Software:

• Microsoft Internet Information Server 4.0
• Microsoft Internet Information Service 5.0

General Information

Technical details

Technical description:

This vulnerability involves a new variant of the "File Fragment Reading via .HTR" vulnerability, previous variants of which were discussed in Microsoft Security Bulletins MS00-031 and MS00-044. Like the original variants, this one could enable an attacker to request a file in a way that would cause it to be processed by the .HTR ISAPI extension. The result of doing this is that fragments of server-side files like .ASP files could potentially be sent to the attacker.

Customers who have previously disabled the .HTR functionality would not be affected by this vulnerability. Microsoft recommends that all customers who haven't already disabled .HTR do so, unless there is a business-critical reason for keeping it. For the latter group of customers, the patch below will eliminate this vulnerability, as well as those discussed in Microsoft Security Bulletins MS00-031 and MS00-044.

Mitigating factors:

• The effect of normal .HTR processing would be to strip out the very data that would be most likely to contain sensitive data.
• There would need to be zeros in fortuitous locations in the server memory in order for the file fragments to be sent.
• If best practices have been followed regarding the need to avoid ever storing sensitive information in .ASP and other server-side files, there will be no sensitive information in the file to begin with.
• There is no capability via the vulnerability to add, change or delete files on the server, or to access a file without permissions

Vulnerability identifier: CAN-2001-0004

Frequently asked questions

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.

Patch availability

Download locations for this patch

As noted above, the recommended method of eliminating this vulnerability is to disable .HTR. (Instructions for doing this are provided in the FAQ). Customers who must retain the .HTR functionality should apply the patch:

• IIS 4.0:

  https://www.microsoft.com/download/details.aspx?FamilyId=A8270ADC-A836-4B32-A7AF-9E7BE14845A5&displaylang;=en

• IIS 5.0:

  https://www.microsoft.com/download/details.aspx?FamilyId=04FAB0BC-D950-4E64-8672-2731756B72FE&displaylang;=en

Additional information about this patch

Installation platforms:

• The IIS 4.0 patch can be installed on systems running Windows NT 4.0 Service Packs 5 and 6a.
• The IIS 5.0 patch can be installed on systems running Windows 2000 Gold and Service Packs 1 and 2.

Inclusion in future service packs:

• The fix for the IIS 4.0 issue will be included in Windows NT 4.0 Service Pack 7.
• The fix for the IIS 5.0 issue will be included in Windows 2000 Service Pack 3.

Verifying patch installation:

• IIS 4.0:

  • To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine:

    HKLM\software\Microsoft\Windows NT\CurrentVersion\Hotfix\Q285985.

  • To verify the individual files, consult the file manifest in Knowledge Base article Q285985

• IIS 5.0:

  • To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows 2000\SP3\Q285985.

  • To verify the individual files, use the date/time and version information provided in the following registry key:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows 2000\SP3\Q285985\Filelist

Caveats:

Microsoft strongly recommends disabling the .HTR mappings in IIS as a preferable option over installing the patch. Only customers who have a business-critical need for .HTR should retain the functionality.

Localization:

Localized versions of this patch are under development. When completed, they will be available at the locations discussed in "Obtaining other security patches".

Obtaining other security patches:

Patches for other security issues are available from the following locations:

• Security patches are available from the Microsoft Download Center, and can be most easily found by doing a keyword search for "security_patch".
• Patches for consumer platforms are available from the WindowsUpdate web site

Other information:

Support:

• Microsoft Knowledge Base article Q285985 discusses this issue and will be available approximately 24 hours after the release of this bulletin. Knowledge Base articles can be found on the Microsoft Online Support web site.
• Technical support is available from Microsoft Product Support Services. There is no charge for support calls associated with security patches.

Security Resources: The Microsoft TechNet Security Web Site provides additional information about security in Microsoft products.

Disclaimer:

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.

Revisions:

• V1.0 (January 29, 2001): Bulletin Created.
• V1.1 (November 04, 2003): Updated links to Windows Update in Additional Information.

Built at 2014-04-18T13:49:36Z-07:00