Security Bulletin

Microsoft Security Bulletin MS02-028 - Critical

Heap Overrun in HTR Chunked Encoding Could Enable Web Server Compromise (Q321599)

Published: June 12, 2002 | Updated: February 28, 2003

Version: 2.1

Originally posted: June 12, 2002

Updated: February 28th, 2003

Summary

Who should read this bulletin: Customers hosting web servers using Microsoft® Windows NT® 4.0 or Windows® 2000.

Impact of vulnerability: Run code of an attacker's choice on the system

Maximum Severity Rating: Critical

Recommendation: Customers who have a business-critical reason for retaining HTR scripting should apply the patch immediately. All others should ensure HTR is disabled.

Affected Software:

• Microsoft Internet Information Server 4.0
• Microsoft Internet Information Services 5.0

General Information

Technical details

Technical description:

On June 12, 2002, Microsoft released the original version of this bulletin. On July 1, 2002, the bulletin was updated to revise the severity rating. Specifically, Microsoft has increased the severity rating of this issue to "critical ." The revision is in response to a significant change in the threat environment due to an increased focus on chunked encoding vulnerabilities in general, and the discovery of hostile code attempting to exploit similar vulnerabilities on other platforms. Customers who have already disabled HTR or applied this patch need not take any action. Customers who have not disabled HTR should do so as soon as possible. Alternately, customers who cannot disable HTR should apply the patch immediately.

This patch eliminates a newly discovered vulnerability affecting Internet Information Services. Although Microsoft typically delivers cumulative patches for IIS, in this case we have delivered a patch that eliminates only this new vulnerability, while completing a cumulative patch. When the cumulative patch is customer-ready, we will update this bulletin with information on its availability. The FAQ provides information on the circumstances surrounding the vulnerability, and why we believe releasing a singleton patch immediately is in customers' best interests. To ensure that servers are fully protected against past as well as current vulnerabilities, we strongly recommend installing the previous cumulative patch (discussed in Microsoft Security Bulletin MS02-018) before installing this patch.

The vulnerability is similar to the first vulnerability discussed in Microsoft Security Bulletin MS02-018. Like that vulnerability, this one involves a buffer overrun in the Chunked Encoding data transfer mechanism in IIS 4.0 and 5.0, and could likewise be used to overrun heap memory on the system, with the result of either causing the IIS service to fail or allowing code to be run on the server. The chief difference between the vulnerabilities is that the newly discovered one lies in the ISAPI extension that implements HTR - an older, largely obsolete scripting technology - where the previous one lay in the ISAPI extension that implements ASP.

Mitigating factors:

• Microsoft has long recommended disabling HTR functionality unless there is a business-critical reason for retaining it. Systems on which HTR is disabled would not be at risk from this vulnerability.
• The IIS Lockdown Tool disables HTR by default in all server configurations.
• The current version of the URLScan tool provides a means of blocking chunked encoding transfer requests by default.
• On default installations of IIS 5.0, exploiting the vulnerability to run code would grant the attacker the privileges of the IWAM_computername account, which has only the privileges commensurate with those of an interactively logged-on unprivileged user.

Severity Rating:

The above assessment is based on the types of systems affected by the vulnerability, their typical deployment patterns, and the effect that exploiting the vulnerability would have on them. Although the vulnerability would grant varying degrees of control to a successful attacker, depending on the particular version in use, a server configured using any of the Microsoft security checklists or security tools would not have the HTR functionality enabled.

Vulnerability identifier: CAN-2002-0364

Tested Versions:

Microsoft tested IIS 4.0, 5.0 and 5.1 to assess whether they are affected by these vulnerabilities. Previous versions are no longer supported, and may or may not be affected by these vulnerabilities. IIS 6.0 is a beta product, and beta products are typically not eligible for security patches; however, we have confirmed that no beta versions of IIS 6.0 are affected by the vulnerability.

Frequently asked questions

Why was this bulletin updated?
On July 1, 2002, we updated this bulletin to advise customers of a revision in the severity rating of this issue. Specifically, we have increased the rating for this issue to "critical" because of new information that materially changes the threat environment. Specifically, we have become aware of increased interest and activity surrounding chunked encoding vulnerabilities in general, and are aware of attempts to exploit similar issues on other platforms. While Microsoft is not currently aware of any attempts to maliciously exploit this specific issue, we feel that this activity constitutes an increased threat. We have proactively revised the severity rating to "critical" to more accurately represent this threat and we are urging all customers to immediately disable HTR mappings if at all possible. Those customers who cannot disable HTR mappings are urged to apply the patch immediately. Customers who have already taken steps to address this issue need not take any action.

Is this a cumulative patch?
No. This patch eliminates a newly discovered security vulnerability, but it is not cumulative. A cumulative patch for this issue and others is under development, and will be completed shortly. When it is available, we will update this bulletin to provide information on how to obtain it. Because this patch is not cumulative, we recommend that customers ensure that they have installed the most recent cumulative patch (delivered in Microsoft Security Bulletin MS02-018) before installing this patch.

I thought Microsoft's policy was to provide cumulative patches for IIS. Why isn't this patch cumulative?
Microsoft's normal policy is to provide security fixes for IIS via cumulative patches. In fact, a cumulative patch has been underway for several weeks. However, cumulative patches require extensive testing because of their scope and wide deployment. As a result, the cumulative patch is several weeks away from being customer-ready. The newly discovered vulnerability is similar to another vulnerability (discussed in Microsoft Security Bulletin MS02-018), for which exploit tools are already available. At the same time, eliminating the vulnerability required only a small amount of code change, in a component with few dependencies on other code. As a result, we concluded that there was high value in developing a singleton patch and that we could do so in a much shorter timeframe than usual.

If I don't want to install the patch, is there a workaround procedure for this vulnerability?
Yes. As discussed below, the vulnerability can be eliminated by disabling a rarely used feature in IIS. Customers who have already disabled this feature don't need to take any additional action.

What's the scope of the vulnerability?
This is a buffer overrun vulnerability affecting IIS 4.0 and 5.0. By sending a specially chosen request to an affected web server, an attacker could either disrupt web services or gain the ability to run a program on the server. Such a program would run with full system privileges in IIS 4.0, and with fewer but nevertheless significant privileges in IIS 5.0 Microsoft has long recommended that customers remove the functionality that contains the vulnerability unless there is a business-critical reason for retaining it, and customers who have done so would be at no risk from this vulnerability. The IIS Lockdown Tool disables this functionality by default. Customers who have retained the functionality but deployed the URLScan tool as discussed in Microsoft Security Bulletin MS02-018 would likewise be protected against the vulnerability.

What causes the vulnerability?
The vulnerability results because of an arithmetic error in the ISAPI extension that implements the HTR functionality. Specifically, the error lies in a function that enables data to be uploaded to a web server via chunked encoding, and causes IIS to allocate a buffer of the wrong size to hold incoming data, with the result that the data could overrun the end of the buffer.

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 -- a dynamic link library (.dll) that uses ISAPI to respond to events that occur on the server.
• As an ISAPI extension -- a dynamic link library that uses ISAPI to provide a set of web functions above and beyond those natively provided by IIS.

In the case of this vulnerability, the affected code is an ISAPI extension that implements scripting via HTR.

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. However, all versions of IIS through version 5.1 do provide support for HTR, for purposes of backward compatibility. Microsoft has long advocated that customers disable HTR on their web servers, unless there is a business-critical need for the technology. By default, the IIS Lockdown Tool disables HTR support, by unmapping the HTR ISAPI extension.

Are there any widespread uses for HTR?
Virtually the only purpose for which HTR technology is still used today is web-based password management services. IIS ships with a set of HTR scripts that, if deployed, make it possible for users to change their Windows NT passwords via a web server, and make it possible for administrators to perform password management through the web. In general, Microsoft recommends against performing password management over the web. However, for customers who must do this, we recommend converting any needed HTR scripts to ASP.

What is chunked encoding?
Web servers frequently need the ability to accept data from a user. For instance, when a visitor to a web site fills in a form and submits it, the data needs to be uploaded to the server so it can be processed. In cases like this, the amount of data that will be transferred is known in advance, and the server can allocate a buffer of the right size. However, in other scenarios, it's impossible to know beforehand how much data will need to be transferred. For instance, an application might be generating data as it runs, and there might be no way to know exactly how much data it will produce. The HTTP protocol specification provides a way to handle data like this, through a process called chunked encoding. In chunked encoding, the client generates a variable-sized quantity of data called a chunk; it then tells the web server how big the chunk is and sends it. The server allocates a buffer to accommodate the incoming chunk, then receives and processes it. As the client generates additional data, it continues agglomerating it into chunks and delivering them to the server.

What's wrong with the way the HTR ISAPI extension in IIS 4.0 and 5.0 performs chunked encoding transfers?
There's an arithmetic error in the IIS 4.0 and 5.0 HTR implementations, that causes them to miscalculate the size of the buffer that's needed for an incoming chunk and allocate one that's too small. The result is that the data in the chunk can overlap the end of the buffer and overwrite other data in system memory, potentially allowing the operation of IIS to be modified.

How much data could be overwritten?
By design, the client can specify a chunk of any size - if the server can't accommodate a chunk that large, it should send an error message to the client. However, in addition to causing the wrong-sized buffer to be allocated, the arithmetic error also prevents IIS 4.0 and 5.0 from placing any real limits on the size of a chunk. As a result, it would be possible for a client to send a chunk that would overwrite most or all of the memory in the IIS process This is a critical point, because it goes to the heart of why this vulnerability poses a threat to servers. This vulnerability is an example of so-called heap overrun; because of the dynamic nature of system memory, these can be more difficult to exploit than stack overruns and may require more sophisticated skills. Data on the server can change locations from one moment to the next, impeding the attacker's ability to overwrite selected programs or data. However, in this case, the attacker wouldn't need to know where programs were located, but could instead simply overwrite large portions of system memory indiscriminately.

What would this enable an attacker to do?
An attacker who exploited this vulnerability could use it for either of two purposes.

• Service disruption. By overrunning the buffer with random data, the attacker could corrupt program code and cause the IIS service to fail, thereby preventing the server from providing useful service.
• Change the operation of the server. By overrunning the buffer with carefully selected data, the attack could overwrite program code on the server with new program code, in essence modifying the functionality of the server software.

Who could exploit the vulnerability?
Any user who was able to establish a web session with an affected server could exploit the vulnerability.

If the vulnerability were exploited to cause the IIS service to fail, what would be needed to restore normal operation?
On IIS 4.0, the administrator would need to restart the IIS service. On IIS 5.0, the service would automatically restart itself.

Why could the vulnerability only be used to cause the IIS service to fail? If the attacker were able to overwrite system memory indiscriminately, why not overwrite all memory on the server and cause the entire operating system to fail?
Windows NT 4.0, Windows 2000 and Windows XP operate in protected mode. In protected mode, processes can only write to sections of memory they own. As a result, it would not be possible for the attacker to overwrite the memory belonging to the operating system.

If the vulnerability were exploited to change the operation of the server software, what would the attacker be able to do?
In a nutshell, the attacker's code would gain the privileges of the software that called it - the HTR ISAPI extension. The privileges that the attacker could gain would depend on the version of IIS in use on the server:

• On IIS 4.0, the HTR ISAPI extension runs by default in-process - that is, as part of the IIS Service, which runs as part of the operating system itself. As a result, exploiting the vulnerability on a default IIS 4.0 installation would give the attacker complete control over the server.
• On IIS 5.0, the HTR ISAPI extension runs by default out-of-process - that is, in the security context of a special user account called the Web Application Manager. (Web administrators may know this account better as IWAM_computername, where computername is the name of the server). This account has significantly fewer privileges than the IIS service.

What privileges does the Web Application Manager have?
Essentially, the account has the same privileges as those of an unprivileged user who was able to log onto the server interactively. It would not enable an attacker to take administrative action, reconfigure the server, or access important files such as the Security Account Manager database. Nevertheless, it is important not to underestimate the damage that could be caused using even these privileges. Even these privileges could be used to cause significant damage. Worse, the vulnerability could potentially give an attacker a beachhead from which to conduct additional attacks and try to obtain additional privileges.

I'm running IIS 4.0. Can I configure the HTR ISAPI extension to run out-of-process?
You can. However, a better solution is to disable it altogether.

I used the IIS Lockdown Tool to secure my server. Does it disable the HTR ISAPI extension?
Yes. All versions of the IIS Lockdown Tool remove the HTR functionality by default, in all server configurations.

I've deployed the URLScan Tool on my server. Will it protect my system against this vulnerability?
All versions of URLScan beginning with version 2.5 provide the ability to block chunked encoding requests. There are two variants of URLScan, known as "Baseline URLScan" and "URLScan-SRP". The latter variant blocks chunked encoding by default. The former can be configured to block chunked encoding, by adding an entry to the [DenyHeaders] section of URLScan.ini that reads "Transfer-Encoding:". (Note: the quotes should not be included in the entry, but there is a colon at the end of the word "Encoding").

I've disabled the HTR functionality on my IIS server. Do I need the patch?
If you've disabled the HTR functionality, you're at no risk from this vulnerability.

How does the patch eliminate this vulnerability?
The patch eliminates the arithmetic error that causes the vulnerability.

Patch availability

Download locations for this patch

• Microsoft IIS 4.0:

  https:

• Microsoft IIS 5.0:

  </https:>https:

Additional information about this patch

Installation platforms:

• The IIS 4.0 patch can be installed on systems running Windows NT 4.0 Service Pack 6a.
• The IIS 5.0 patch can be installed on systems running Windows 2000 Service Pack 1 or Service Pack 2.

Inclusion in future service packs:

• No additional service packs are planned for Windows NT 4.0.
• The IIS 5.0 fix will be included in Windows 2000 Service Pack 3.

Reboot needed:

• IIS 4.0: A reboot can be avoid by stopping the IIS service, installing the patch with the /z switch, then restarting the service. Knowledge Base article Q319733 provides additional information on this procedure.
• IIS 5.0: No.

Superseded patches: None.

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:

  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\Q321599.

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

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\SP4\Q321599.

• 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\SP4\Q321599\Filelist.

Caveats:

None

Localization:

Localized versions of this patch are available at the locations discussed in "Patch Availability".

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:

Acknowledgments

Microsoft thanks eEye Digital Security for reporting this issue to us and working with us to protect customers.

Support:

• Microsoft Knowledge Base article Q321599 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 (June 12, 2002): Bulletin Created.
• V1.1 (June 13, 2002): FAQ item updated.
• V1.2 (June 20, 2002): Correction made in the Verifying patch installation for IIS 5.0 section.
• V2.0 (July 1, 2002): Severity rating updated to reflect changing threat environment.
• V2.1 (February 28, 2003): Updated download links to Windows Update.

Built at 2014-04-18T13:49:36Z-07:00 </https:>