TechNet Home >  Security >  Bulletins

   Microsoft Security Bulletin MS02-028
                                                            [Print] Print

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

  Originally posted: June 12, 2002
  Updated: July 1, 2002

  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

  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:
                Internet Servers  Intranet Servers Client Systems

        IIS 4.0 Critical          Critical         Critical

        IIS 5.0 Critical          Critical         Critical
       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:
            http://www.microsoft.com/Downloads/Release.asp?ReleaseID=39579
          * Microsoft IIS 5.0:
            http://www.microsoft.com/Downloads/Release.asp?ReleaseID=39217

  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
          * All patches available via WindowsUpdate also are
            available in a redistributable form from the
            WindowsUpdate Corporate 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.

  Contact Us   |   E-mail this Page   |   TechNet Newsletter

  © 2002 Microsoft Corporation. All rights reserved.     Terms of Use    Privacy Statement    Accessibility