Microsoft Security Bulletin MS02-018

Technical description:

This patch is a cumulative patch that includes the functionality of all security patches released for IIS 4.0 since Windows NT 4.0 Service Pack 6a, and all security patches released to date for IIS 5.0 and 5.1. A complete listing of the patches superseded by this patch is provided below, in the section titled "Additional information about this patch". Before applying the patch, system administrators should take note of the caveats discussed in the same section.

In addition to including previously released security patches, this patch also includes fixes for the following newly discovered security vulnerabilities affecting IIS 4.0, 5.0 and/or 5.1:

• A buffer overrun vulnerability involving the operation of the chunked encoding transfer mechanism via Active Server Pages in IIS 4.0 and 5.0. An attacker who exploited this vulnerability could 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.
• A Microsoft-discovered vulnerability that is related to the preceding one, but which lies elsewhere within the ASP data transfer mechanism. It could be exploited in a similar manner as the preceding vulnerability, and would have the same scope. However, it affects IIS 4.0, 5.0, and 5.1.
• A buffer overrun involving how IIS 4.0, 5.0 and 5.1 process HTTP header information in certain cases. IIS performs a safety check prior to parsing the fields in HTTP headers, to ensure that expected delimiter fields are present and in reasonable places. However, it is possible to spoof the check, and convince IIS that the delimiters are present even when they are not. This flaw could enable an attacker to create an URL whose HTTP header field values would overrun a buffer used to process them.
• A Microsoft-discovered buffer overrun vulnerability in IIS 4.0, 5.0 and 5.1 that results from an error in safety check that is performed during server-side includes. In some cases, a user request for a web page is properly processed by including the file into an ASP script and processing it. Prior to processing the include request, IIS performs an operation on the user-specified file name, designed to ensure that the file name is valid and sized appropriately to fit in a static buffer. However, in some cases it could be possible to provide a bogus, extremely long file name in a way that would pass the safety check, thereby resulting in a buffer overrun.
• A buffer overrun affecting the HTR ISAPI extension in IIS 4.0 and 5.0. By sending a series of specially malformed HTR requests, it could be possible to either cause the IIS service to fail or, under a very difficult operational scenario, to cause code to run on the server.
• A denial of service vulnerability involving the way IIS 4.0, 5.0, and 5.1 handle an error condition from ISAPI filters. At least one ISAPI filter (which ships as part of FrontPage Server Extensions and ASP.NET), and possibly others, generate an error when a request is received containing an URL that exceeds the maximum length set by the filter. In processing this error, the filter replaces the URL with a null value. A flaw results because IIS attempts to process the URL in the course of sending the error message back to the requester, resulting in an access violation that causes the IIS service to fail.
• A denial of service vulnerability involving the way the FTP service in IIS 4.0, 5.0 and 5.1 handles a request for the status of the current FTP session. If an attacker were able to establish an FTP session with an affected server, and levied a status request that created a particular error condition, a flaw in the FTP code would prevent it from correctly reporting the error. Other code within the FTP service would then attempt to use uninitialized data, with an access violation as the result. This would result in the disruption of not only FTP services, but also of web services.
• A trio of Cross-Site Scripting (CSS) vulnerabilities affecting IIS 4.0, 5.0 and 5.1: one involving the results page that's returned when searching the IIS Help Files, one involving HTTP error pages; and one involving the error message that's returned to advise that a requested URL has been redirected. All of these vulnerabilities have the same scope and effect: an attacker who was able to lure a user into clicking a link on his web site could relay a request containing script to a third-party web site running IIS, thereby causing the third-party site's response (still including the script) to be sent to the user. The script would then render using the security settings of the third-party site rather than the attacker's.

Mitigating factors:

Buffer overrun in Chunked Encoding transfer:

• On default installations of IIS 5.0 and 5.1, 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.
• The vulnerability requires that Active Server Pages (ASP) be enabled on the system in order to be exploited. Version 1.0 of the IIS Lockdown Tool removes ASP by default, and the current version (version 2.1) removes it by default if Static Web Server has been selected.
• The URLScan tool can be configured to prevent chunked encoding requests. If this has been done, the vulnerability could not be exploited.

Microsoft-discovered variant of Chunked Encoding buffer overrun:

• This vulnerability is subject to exactly the same mitigating factors as the buffer overrun in the Chunked Encoding transfer, with one exception. The URLScan tool could not be used to protect against the vulnerability.

Buffer Overrun in HTTP header handling:

• On default installations of IIS 5.0 and 5.1, 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.
• The vulnerability requires that Active Server Pages (ASP) be enabled on the system in order to be exploited. Version 1.0 of the IIS Lockdown Tool removes ASP by default, and the current version (version 2.1) removes it by default if Static Web Server has been selected.
• The URLScan tool's default ruleset would likely limit the attacker to using this vulnerability for denial of service attacks only.

Buffer Overrun in ASP Server-Side Include Function:

• On default installations of IIS 5.0 and 5.1, 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 user.
• The vulnerability requires that Active Server Pages (ASP) be enabled on the system in order to be exploited. Version 1.0 of the IIS Lockdown Tool removes ASP by default, and the current version (version 2.1) removes it by default if Static Web Server has been selected.
• The URLScan tool's default ruleset would likely limit the attacker to using this vulnerability for denial of service attacks only.

Buffer overrun in HTR ISAPI extension:

• Microsoft has long recommended disabling the HTR ISAPI extension. Systems on which this has been done would be at no risk from the vulnerability. (All versions of the IIS Lockdown Tool disable HTR support by default).
• The URLScan tool, if using its default ruleset, would prevent this vulnerability from being exploited to run code on the server even if HTR support was enabled.
• The vulnerability could only be used to run code on the server if the attacker knew the locations of certain information in memory. In practice, the most likely such situation would occur if the web server had never served any web content since being rebooted. In all other cases, it would only be possible to use the vulnerability for denial of service attacks.
• On default installations of IIS 5.0 and 5.1, 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 user.
• If the vulnerability were used in a denial of service attack, normal operation could be restored on an IIS 4.0 server by restarting the IIS service; on IIS 5.0 and higher, the service would automatically restart itself.

Access violation in URL error handling:

• An IIS 4.0 server could be put back into normal operation by restarting the service. An IIS 5.0 or 5.1 server would automatically restart the service.
• The vulnerability could only be used for denial of service attacks. There is no capability to use the vulnerability to gain privileges on the system.
• The sole ISAPI filter known to generate the error that results in the access violation ships only as part of FrontPage Server Extensions and ASP.NET. ASP.NET is not installed by default, and FPSE can be uninstalled if desired.

Denial of service via FTP Status request:

• The IIS Lockdown Tool disables FTP support by default.
• An IIS 4.0 server could be put back into normal operation by restarting the service. An IIS 5.0 or 5.1 server would automatically restart the service.
• The vulnerability could only be used for denial of service attacks. There is no capability to use the vulnerability to gain privileges on the system.

Cross-site Scripting in IIS Help File search facility, HTTP Error Page, and Redirect Response message:

• The vulnerabilities could only be exploited if the attacker could entice another user into visiting a web page and clicking a link on it, or opening an HTML mail.
• The Redirect Response vulnerability could only be exploited if the user was running a browser other than Internet Explorer. IE does not actually render the text in the Redirect Response, but instead recognizes it by its response header and processes the redirect without displaying any text.

Severity Rating:

Buffer overrun in ASP Chunked Encoding data transfer mechanism:

Microsoft-discovered variant of ASP Chunked Encoding buffer overrun:

Buffer Overrun in HTTP Header Handling:

Buffer Overrun in ASP Server-Side Include Function:

Buffer overrun in HTR ISAPI extension:

Access violation in URL error handling:

Denial of service via FTP status request:

Cross-site Scripting in IIS Help File search facility:

Cross-site Scripting in HTTP Error Page:

Cross-site Scripting in Redirect Response message:

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.

Vulnerability identifiers:

• Buffer overrun in Chunked Encoding mechanism: CAN-2002-0079
• Microsoft-discovered variant of Chunked Encoding buffer overrun: CAN-2002-0147
• Buffer Overrun in HTTP Header handling: CAN-2002-0150
• Buffer Overrun in ASP Server-Side Include Function: CAN-2002-0149
• Buffer overrun in HTR ISAPI extension: CAN-2002-0071
• Access violation in URL error handling: CAN-2002-0072
• Denial of service via FTP status request: CAN-2002-0073
• Cross-site Scripting in IIS Help File search facility: CAN-2002-0074
• Cross-site Scripting in HTTP Error Page: CAN-2002-0148
• Cross-site Scripting in Redirect Response message: CAN-2002-0075

Tested Versions:

The following table indicates which of the currently supported versions of IIS are affected by the vulnerabilities. Versions prior to IIS 4.0 are no longer supported and may or may not be affected by these vulnerabilities. IIS 6.0 is a beta product and is therefore not intended for use in production systems. A small number of customers are deploying IIS 6.0 servers in product environments as part of a joint program with Microsoft, and patches will be delivered directly to them.

What vulnerabilities are eliminated by this patch?
This is a cumulative patch that, when applied, eliminates most security vulnerabilities affecting Internet Information Server (IIS) 4.0 (exceptions are listed below in the Caveats section) and all vulnerabilities affecting Internet Information Service 5.0 and 5.1. In addition to eliminating previously discussed vulnerabilities, it also eliminates several new ones:

• A vulnerability that could enable an attacker to gain control over a web server running IIS 4.0 or 5.0.
• A Microsoft-discovered vulnerability with the same risk and effect as the preceding vulnerability, but which affects IIS 4.0, 5.0, and 5.1.
• A vulnerability that could enable an attacker to gain control over a web server running IIS 4.0 or 5.0.
• A Microsoft-discovered vulnerability that could enable an attacker to gain control over a web server running IIS 4.0, 5.0 or 5.1.
• A vulnerability that could, under unusual conditions, enable an attacker to gain control over a web server running IIS 4.0 or 5.0.
• A vulnerability that could enable an attacker to prevent an IIS 4.0, 5.0 or 5.1 web server from providing service.
• A vulnerability that could enable an attacker to prevent an FTP server on an IIS 4.0, 5.0, or 5.1 server from providing service.
• Three vulnerabilities that could enable an attacker to "bounce" web content to another user's browser session through an IIS 4.0, 5.0 or 5.1 web server.

What products do IIS 4.0, 5.0, and 5.1 ship with?

• Internet Information Server 4.0 ships as part of the Windows NT 4.0 Option Pack (NTOP)
• Internet Information Service 5.0 ships as part of Windows 2000 Datacenter Server, Advanced Server, Server and Professional.
• Internet Information Service 5.1 ships as part of Windows XP Professional. It does not ship as part of Windows XP Home Edition.

Do IIS 4.0, 5.0 and 5.1 run by default?

• IIS 4.0 runs by default when the NTOP is installed on a Windows NT 4.0 server. It does not run by default when the NTOP is installed on a Windows NT 4.0 workstation, unless Peer Web Services were already running when it was installed.
• IIS 5.0 runs by default on all Windows 2000 server products. It does not run by default on Windows 2000 Professional.
• IIS 5.1 does not run by default on Windows XP.

Does the patch include any other fixes?
Yes. In addition to eliminating the security vulnerabilities discussed above, the patch also includes a small number of fixes for issues that aren't security vulnerabilities. These are documented in Microsoft Knowledge Base article Q319733

Some of the vulnerabilities apply to certain versions of IIS, but not to others. How do I know whether I need a patch for my version?
If you're running any of the affected products, you should install the patch. The patch will only apply the fixes for the vulnerabilities affecting your version of IIS.

Above and beyond staying up to date on patches, are there any other steps I should take to maintain the security of my web server?
The single most important step you can take to keep your web server secure is to use the IIS Lockdown Tool. The tool will ensure that your server is configured securely and will install the URLScan tool to provide continuing protection while the server is operating.
In addition, there are small number of vulnerabilities affecting IIS 4.0 that cannot be eliminated via software patches. Instead, they require administrative action. All such vulnerabilities are listed below in the Caveats section.

Can these patches be installed on systems running Personal Web Server or Peer Web Services?
In some cases, they can. If you are running either Personal Web Server or Peer Web Services, please consult Microsoft Knowledge Base Article Q307439 for specific information.

Why haven't you discussed IIS 6.0 in the context of these vulnerabilities?
We typically don't discuss beta products in security bulletins. By definition, beta products are incomplete; they're intended for evaluation purposes and shouldn't be used in production systems. A small number of customers are engaged in production deployments of IIS 6.0 in conjunction with Microsoft, and we are delivering fixes directly to them.

Buffer Overrun in Chunked Encoding Transfer (CVE-CAN-2002-0079)

What's the scope of this 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
Customers who have used the IIS Lockdown Tool to configure their servers as static web servers are already protected against the vulnerability. Likewise, the URLScan tool can be configured to block the vulnerability, and affected mechanism itself can be disabled. However, because of the seriousness of the vulnerability, we do recommend that all customers install the patch, including those who have already taken these steps.

What causes the vulnerability?
The vulnerability results because of an arithmetic error in the ISAPI extension that implements the Active Server Pages (ASP) 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 Active Server Pages.

What are Active Server Pages?
Active Server Pages (ASP) is a technology that allows web servers to dynamically generate web applications. One way to visualize Active Server Pages is consider them to be programs that resides on the web server; when a user requests an ASP page, the ASP ISAPI extension processes the ASP page, generates an HTML page, and sends it to the user. The vulnerability in this case doesn't involve the ASP technology per se, but instead involves an error in how a standard type of data transfer operation called chunked encoding is implemented in 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 IIS 4.0 and 5.0 perform chunked encoding transfers?
There's an arithmetic error in the IIS 4.0 and 5.0 Active Server Pages 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 on the system
This is a critical point, because it goes to the heart of why this vulnerability poses such a serious threat to servers. This vulnerability is an example of so-called heap overrun; these are frequently difficult or impossible to exploit, because of the dynamic nature of system memory. 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 ASP ISAPI extension, ASP.DLL. The privileges that the attacker could gain would depend on the version of IIS in use on the server:

• On IIS 4.0, ASP.DLL 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, ASP.DLL 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 ASP.DLL to run out-of-process?
Yes. Microsoft has long recommended that, whenever possible, IIS 4.0 should be configured to run ASP.DLL and other components out-of-process. This not only improves security, but stability as well. There is, however, a performance penalty associated with running out of process.

I don't use Active Server Pages. Would disabling the functionality altogether protect my server?
Yes. In fact, Version 1.0 of the IIS Lockdown Tool disabled ASP by default. The current version of the Tool, version 2.1, provides a number of different server roles. Selecting "Static Web Server" will disable ASP by default.

I've deployed the URLScan Tool on my server. Will it protect my system against this vulnerability?
By default, it would not. However, it would be possible add a rule that would block chunked encoding requests. Just add 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")
Microsoft has release an updated version of the URLScan that implements this rule by default, as well as improving the protection the tool can provide. The updated tool is available for download at http://www.microsoft.com/technet/security/tools/urlscan.mspx.

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

Microsoft-discovered variant of Chunked Encoding buffer overrun (CVE-CAN-2002-0147)

What's the scope of this vulnerability?
This vulnerability is identical to the preceding one in scope, effect, and remediation. There are only two significant differences:

• This vulnerability affects additional versions of IIS. Specifically, it affects IIS 4.0, 5.0 and 5.1.
• It cannot be blocked by URLScan.

What causes this vulnerability?
This vulnerability results because of a handling error in the allocation of buffers for data transfers. Although it involves a similar functionality as preceding one, and has the same overall effect, there are nevertheless some important differences between the two vulnerabilities.

What are the differences between this vulnerability and the preceding one?
There are two primary differences. First, where IIS 5.1 is not affected by the preceding one, it is affected by this one. Second, unlike the preceding vulnerability, this one could not be blocked via URLScan.

How was this vulnerability found?
Microsoft discovered this vulnerability through code inspection as part of the investigation of the preceding one.

Buffer Overrun in ASP Server-Side Include Function (CVE-CAN-2002-0149)

What's the scope of this vulnerability?
This is a buffer overrun vulnerability affecting IIS 4.0, 5.0 and 5.1. 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 and 5.1
Customers who have used the IIS Lockdown Tool to configure their servers as static web servers are already protected against the vulnerability. Likewise, the URLScan tool, when deployed with the default ruleset, would make it difficult to use the vulnerability to gain control of the server, and likely reduce it to a denial of service attack only.

What causes the vulnerability?
The vulnerability results because of a logic error in a function that handles server-side file includes for Active Server Pages. The result of the error is that the function could conclude that it is safe to store the name of a specified server-side file in a particular buffer, when in actuality the filename is longer than the buffer

What are server-side file includes?
Frequently, developers need to be able to incorporate a file into a program - for instance, as a way of reusing existing code. File includes provide a way to do this. The developer specifies what file should be included in the program, and at what point, and the contents of the file are treated as though they were part of the program.
ASP, like most programming languages, supports file includes. In the case of ASP, the included files come from the web server itself, so they're known as server-side file includes. When an ASP script runs, a pre-processing step handles any file includes, after which point the ASP ISAPI filter processes the result.

Can a visitor to a web site request a server-side include?
No. After all, a web site visitor should never actually be involved in the operation of ASP scripts - all processing should occur on the server. However, it is possible for user actions to have the effect of causing a file include on the server to happen. This vulnerability involves the operation of IIS when this is done, and in a particular way.

What's wrong with how IIS handles server-side includes?
In some cases, requesting a particular web page will cause it to be included within an ASP script as part of its processing. Because this involves putting user input into a buffer, IIS always performs a check beforehand, designed to make sure the input is valid. Specifically, it performs an operation on the file name that should only succeed if the file name is valid.
A security vulnerability results because it's possible to levy a request that includes a very long, invalid file name, but do it in a way that has two effects. First, the ASP ISAPI extension concludes that the filename needs to be processed as part of an ASP file, and does a server-side include. Second, the filename evades the safety check. The result is that the file name - which is longer than the buffer allocated to hold it - causes a buffer overrun in the ASP file when it's processed.

What would the vulnerability 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 could establish a session with an affected web server could exploit the vulnerability.

If the vulnerability were exploited to cause the IIS server 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 and 5.1, the service would automatically restart itself.

If the vulnerability were exploited to change the operation of the server software, what would the attacker be able to do?
If exploited in this way, the attacker could gain the same privileges as discussed above:

• On IIS 4.0, the attacker could gain complete control over the server
• On IIS 5.0 and 5.1, the attacker could gain the privileges associated with the Web Application Manager - essentially, those of an unprivileged user.

Would the IIS Lockdown Tool help protect my server?
The vulnerability could only be exploited if Active Server Pages are enabled on the server. Version 1.0 of the IIS Lockdown Tool disables ASP by default. The current version of the Tool, version 2.1, provides a number of different server roles. Selecting "Static Web Server" disables ASP by default.

Would the URLScan tool protect my system against this vulnerability?
It wouldn't offer total protection, but it would significantly reduce the scope of the vulnerability. By default, URLScan blocks all URLs that contain non-ASCII data. This would not prevent an attacker from causing the service to fail - overrunning the buffer with virtually any data would accomplish that goal. However, it would make it difficult to exploit the vulnerability to alter the operation of the server software, because the attacker would need to construct valid executable code using only ASCII data.

How was this vulnerability found?
Microsoft discovered this vulnerability as part of a security review.

How does the patch eliminate the vulnerability?
The patch correct the truncation error, thereby ensuring that the URLs under discussion here will not be passed to the function.

Buffer Overrun in HTTP Header Handling (CVE-CAN-2002-0150)

What's the scope of this vulnerability?
This is a buffer overrun vulnerability affecting IIS 4.0, 5.0 and 5.1. 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 and 5.1.
Customers who have used the IIS Lockdown Tool to configure their servers as static web servers are already protected against the vulnerability. Likewise, the URLScan tool, when deployed with the default ruleset, would prevent this vulnerability from being used to gain control of the server, and reduce it to a denial of service attack only.

What causes the vulnerability?
The vulnerability results because of an error that occurs when Active Server Pages parse HTTP header information. An initial check is performed, with the goal of ensuring that required delimiters are present in the information and in reasonable locations before moving the information in a buffer for processing. However, the check can be spoofed, with a buffer overrun as the result.

What are HTTP headers?
When a client sends a request to a web server, it needs a way to give the web server specific information about the request. For instance, it needs to indicate how data in the request has been formatted, what web browser the client is using, what action the server should perform, and so on. All of this information is specified via fields in the request known as HTTP headers.

What's wrong with the way IIS handles HTTP headers?
When IIS receives an HTTP request, it must parse the headers so it can interpret them and take the appropriate action. This is done by breaking the headers into their constituent parts and putting each in a buffer; IIS determines where each of the parts ends by looking for a delimiting character.

IIS checks before performing this operation, to make sure that the delimiting characters are really present, and located at appropriate places within the request. However, by constructing a request in a particular way, it's possible to spoof this check, and make IIS conclude that the delimiting characters are present when in fact they aren't.

Why does this result in a security vulnerability?
The purpose of the check is to ensure that IIS never copies more information into the buffer than it's designed to hold. However, by spoofing the checks, this protection could be bypassed, resulting in a buffer overrun.
Specifically, suppose an attacker sent a request that contained a large amount of data within the HTTP header fields. Ordinarily, IIS would detect that the data didn't contain the expected delimiters, and that the fields were therefore too large to fit safely in the buffers. It would therefore reject the request. However, if the request was constructed to exploit this vulnerability, IIS would incorrectly conclude that the request was well-formed, and would copy the fields into the buffer, thereby overrunning it.

What would the vulnerability 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 could establish a session with an affected web server could exploit the vulnerability.

If the vulnerability were exploited to cause the IIS server 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 and 5.1, the service would automatically restart itself.

If the vulnerability were exploited to change the operation of the server software, what would the attacker be able to do?
If exploited in this way, the attacker could gain the same privileges as discussed above:

• On IIS 4.0, the attacker could gain complete control over the server
• On IIS 5.0 and 5.1, the attacker could gain the privileges associated with the Web Application Manager - essentially, those of an unprivileged user.

Would the IIS Lockdown Tool help protect my server?
The vulnerability could only be exploited if Active Server Pages are enabled on the server. Version 1.0 of the IIS Lockdown Tool disables ASP by default. The current version of the Tool, version 2.1, provides a number of different server roles. Selecting "Static Web Server" disables ASP by default.

Would the URLScan tool protect my system against this vulnerability?
It wouldn't offer total protection, but it would significantly reduce the scope of the vulnerability. By default, URLScan blocks all URLs that contain non-ASCII data. This would not prevent an attacker from causing the service to fail - overrunning the buffer with virtually any data would accomplish that goal. However, it would make it difficult to exploit the vulnerability to alter the operation of the server software, because the attacker would need to construct valid executable code using only ASCII data.

How does the patch eliminate the vulnerability?
The patch corrects the checking mechanism, and ensures that it's performed correctly in all cases.

Buffer overrun in HTR ISAPI extension (CVE-CAN-2002-0071)

What's the scope of this 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 cause it to temporarily stop providing web services or, in very unusual cases, could gain control of the server.
There are a number of factors that tend to reduce the severity of this vulnerability:

• The most likely effect of exploiting this vulnerability would be to disrupt service on the web server. While it would be possible to use the vulnerability to gain control over the server, it would in most cases require fortuitous circumstances for the attacker.
• The component containing the vulnerability is removed by default by the IIS Lockdown Tool.
• The URLScan tool's default configuration would prevent the vulnerability from being exploited.

What causes the vulnerability?
The vulnerability results because the ISAPI extension that implements HTR scripting contains an off-by-one error when calculating the size of a buffer for storing an input value. If a request for an HTR script were malformed in a particular way, it would be possible to abuse the miscalculation and conduct a buffer overrun attack. In the least serious case, this could result in the failure of the IIS service; in the most serious case (which would be difficult to exploit), it could allow code to be run on the server.

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 disable 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 eneral, 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's wrong with the HTR ISAPI extension?
When the HTR ISAPI extension receives a request to run a script, it calculates the size of the buffer that's needed to contain the request. However, it miscalculates this value, with the result that it creates a buffer one byte smaller than needed. By sending a series of HTR requests, all malformed in particular ways, it could be possible to use the vulnerability to overwrite memory on the server.

What would this enable an attacker to do?
An attacker could exploit this vulnerability in either of two ways. By sending a series of requests that simply overran the buffer with random data, the attacker could cause the service to fail. However, by carefully selecting the data, it could be possible - although operationally difficult - to modify the operation of the IIS service to perform tasks of the attacker's choice.

If the attacker used this vulnerability to cause the service to fail, what would be the result?
If exploited against an IIS 4.0 server, the attack would prevent the server from handling web requests until the administrator restarted the IIS service. If exploited against an IIS 5.0 or 5.1 server, the outage would be only temporary, as the IIS service would automatically restart itself. In either case, any web sessions that were underway when the service failed would be terminated.

If the attacker used this vulnerability to modify the operation of the service, would what be the result?
If exploited in this way, the attacker could gain the same privileges as discussed above:

• On IIS 4.0, the attacker could gain complete control over the server
• On IIS 5.0, the attacker could gain the privileges associated with the Web Application Manager - essentially, those of an unprivileged user.

How difficult would it be to exploit the vulnerability to gain control over the server?
Like the vulnerability discussed above, this is a heap overrun. However, this one would be more difficult to exploit. For instance, it would be more difficult from a technical standpoint to write an exploit tool that takes advantage of a one-byte heap overrun.
Even if an exploit tool were available, the vulnerability could only be exploited under certain conditions. In practical terms, most of these conditions would only be present if the server hadn't serviced any web requests since the last time it was booted, and even then the attacker would need specific information about the software running on the server. Note, however, that none of these factors would be impossible to overcome, given the right circumstances.

I've run the IIS Lockdown Tool. Am I vulnerable to this issue?
By default, the IIS Lockdown Tool disables support for HTR. The vulnerability could not be exploited against a server on which HTR support was disabled.

I have URLScan running. Am I vulnerable to this issue?
URLScan's default ruleset would prevent this vulnerability from being exploited, even if the server was otherwise vulnerable. We do, however, recommend applying the patch on any server on which HTR is enabled, even if URLScan is protecting it.

I'm running a system that's susceptible to the vulnerability. What should I do?
The best course of action is to remove HTR support altogether, by unmapping the HTR ISAPI extension. (The simplest way to do this is via the IIS Lockdown Tool). We recommend retaining HTR support only if there's a business-critical need for it.
Even after removing HTR, we still recommend applying the patch. First, it fixes vulnerabilities in addition to this one. Second, applying the patch will ensure that the server would still be protected even if HTR support were inadvertently re-enabled at some future point.

How does the patch eliminate the vulnerability?
The patch corrects the miscalculation in the HTR ISAPI extension, and ensures that it allocates a buffer that matches the size of the incoming request.

Access violation in URL error handling (CVE-CAN-2002-0072)

What's the scope of this vulnerability?
This is a denial of service vulnerability affecting IIS 4.0, 5.0 and 5.1. By exploiting this vulnerability, an attacker could temporarily prevent a web server from providing web services.
The vulnerability would not allow any data on the system to be compromised, nor would it enable the attacker to gain any privileges on the system. Microsoft's investigations to date suggest that this vulnerability only occurs in cases where Front Page Server Extensions (FPSE) or ASP.NET are installed on the system, although it is possible that it may also occur under other conditions as well.

What causes the vulnerability?
The vulnerability occurs because IIS incorrectly handles the error condition that results when one of the ISAPI filters installed by Front Page Server Extensions and ASP.NET receives an URL that exceeds the maximum allowable length. Although the problem lies within IIS, and therefore could also occur in cases involving additional ISAPI filters, Microsoft's investigations to date have not revealed any others in which this occurs.

What's an ISAPI filter?
As discussed above, an ISAPI filter is a .dll installed to extend the functionality available through a web server. The specific filter at issue in this case is one installed by FPSE and ASP.NET, although others could also be involved as well.

What is FPSE?
FrontPage Server Extensions (FPSE) is a set of tools that can be installed on a web server to allow authorized personnel to manage the server, add or change content, and perform other tasks.

What is ASP.NET?
ASP.NET is a development platform that allows web applications to be built easily and rapidly. ASP.NET can be thought of as a superset of ASP -- existing ASP programs can be ported directly to ASP.NET, but it also provides new, extended functionality.

What's wrong with FPSE and ASP.NET?
Nothing. The problem in this case involves how IIS handles a particular type of error condition that can be generated by ISAPI filters. It happens that the only ISAPI filters Microsoft has identified so far that actually generate the error condition are associated with FPSE and ASP.NET. However, the problem doesn't lie in the ISAPI filter, but rather in the way IIS handles the error condition.
What's the error condition, and why does it cause the IIS service to fail? The error in this case occurs when either of the ISAPI filters receive a request containing an URL that exceeds the maximum length. When this happens, the filter fails the request, and sets the URL to a null value. The vulnerability results because IIS, before sending the response back to the requester, tries to use the URL. This causes an access violation that results in the failure of the IIS service.

What would this enable an attacker to do?
An attacker who exploited this vulnerability would be able to cause the IIS service to fail. This would have the effect of terminating any sessions that were in process at the time, and preventing any new ones until the service was restarted.

How might an attacker exploit the vulnerability?
An attacker could exploit the vulnerability by sending to an affected server a request that would be processed by either of the ISAPI filters mentioned above, and including an URL that exceeds the maximum length for the filter. (Likewise, if there were other ISAPI filters installed on the system that can generate the same error condition, the attacker could send a request to one of them).

What would be required to resume normal operation?
On IIS 4.0, the operator would need to restart the service. On IIS 5.0 and 5.1, the service would automatically restart itself.

Could the attacker gain any other privileges on the server via this vulnerability?
No. This is strictly a denial of service vulnerability; there is no capability to change content on the server, manage it, or take any other actions.

I haven't installed FPSE on my server. Could I be affected by the vulnerability?
Some of the Server Extensions install as part of IIS 4.0, 5.0 and 5.1 by default, and others must be installed separately. The ISAPI filter at issue here installs by default, so a server would be affected unless the administrator had removed FPSE. (FPSE can be removed via the Add/Remove Programs applet in Control Panel). Even if FPSE has been removed, keep in mind that it could be possible for a server to have other ISAPI filters installed that would generate the error condition that causes IIS to fail.

I haven't installed ASP.NET on my server. Could I be affected by the vulnerability?
ASP.NET does not install by default as part of IIS. However, even if ASP.NET is not installed on the system, FPSE would be, as discussed in the preceding paragraph.

How does the patch eliminate this vulnerability?
The patch cause IIS to check the URL when processing the error at issue here, and to not attempt to process it.

Denial of service via FTP status request (CVE-CAN-2002-0073)

What's the scope of this vulnerability?
This is a denial of service vulnerability affecting IIS 4.0, 5.0 and 5.1. By exploiting this vulnerability, an attacker could temporarily prevent a web server from providing web services.
The vulnerability could only be exploited if the web server were also configured to provide FTP services. IIS 4.0 installs FTP services by default, but IIS 5.0 and 5.1 do not. The IIS Lockdown Tool disables FTP support by default. The vulnerability would not allow any data on the system to be compromised, nor would it enable the attacker to gain any privileges on the system.

What causes the vulnerability?
The vulnerability results because the FTP implementation in IIS 4.0, 5.0 and 5.1 does not correctly handle a request for the status of the connection, if the request has been malformed in a particular way. Receiving such a request would result in the failure of the IIS service.

What is FTP?
File Transfer Protocol (FTP) is an industry standard protocol (specified in RFC 959) that allows users to post files to or retrieve files from a server. All versions of IIS include an implementation of the protocol.

What's wrong with the FTP implementation in IIS 4.0, 5.0 and 5.1?
They contain an error in the way they handle a request for the status of an ongoing FTP connection. Specifically, including certain characters in the request creates an error condition, but this fact isn't correctly reported back to the software module that relayed the user's request. The result is that the calling module uses uninitialized data, thereby causing an access violation.

What would this enable an attacker to do?
FTP services are provided by the IIS service itself, so an attacker who exploited this vulnerability would be able to disrupt not only FTP services but web services as well. This would have the effect of terminating any sessions that were in effect at the time of the attack.

Who could exploit this vulnerability?
Any user who was able to establish an FTP session with an affected server could exploit the vulnerability. The status request that contains the flaw can only be levied as part of an already existing session.

What would be required to resume normal operation?
On an IIS 4.0 server, the operator would need to restart the IIS service. On IIS 5.0 and 5.1 servers, the service would automatically restart itself.

What's the significance of the need for the attacker to be able to establish a session with the server?
It means that an attacker could not simply conduct a "drive-by" attack and send data to the server. The FTP service would need to be enabled and running, and the attacker would either need logon credentials, or the server would need to be configured to allow anonymous logon.

Does FTP install and run by default?
It is enabled and running by default as part of IIS 4.0, but not as part of IIS 5.0 or 5.1. It's also worth noting that the IIS Lockdown Tool disables FTP by default.

If FTP is running, is anonymous logon enabled by default?
Yes. It's always a good idea to consider whether you really want to allow anonymous access to your FTP server, and to disable it if this isn't the case.

How does the patch eliminate the vulnerability?
The patch causes the FTP service to correctly handle the command at issue here.

Cross-site Scripting in IIS Help File search facility, Redirect Response message, and HTTP Error Page (CVE-CAN-2002-0074, 0075, 0148)

What's the scope of these vulnerabilities?
These are all cross-site scripting vulnerabilities. The scope and effect of all of them is the same -- through these vulnerabilities, it could be possible for an attacker to send a request to an affected server that would cause a web page containing script to be sent to another user. The script would execute within the user's browser as though it had come from the third-party site. This would let it run using the security settings appropriate to the third-part web site, as well as allowing the attacker to access any data belonging to the site.
The vulnerability could only be exploited if the user opened an HTML mail or visited a malicious user's web site - the code could not be "injected" into an existing session. In one of the two cases here, even if an attacker did exploit the vulnerability, it would have no effect on a user running IE. What causes the vulnerability? Certain web services provided by IIS don't properly validate all inputs before using them, and are consequently vulnerable to Cross-Site Scripting (CSS).

What's Cross-Site Scripting?
CSS is a security vulnerability that potentially enables a malicious user to "inject" code into a user's session with a web site. Unlike most security vulnerabilities, CSS doesn't apply to any single vendor's products - instead, it can affect any software that runs on a web server and doesn't follow defensive programming practices. In early 2000, Microsoft and CERT worked together to inform the software industry of the issue and lead an industry-wide response to it.

How does CSS work?
A good description is available in the form of an executive summary and a FAQ. However, at a high level of detail, here's how CSS works. Suppose Web Site A offers a search feature that lets a user type a word or phrase to search for. If the user typed "banana" in as the search phrase, the site would search for the phrase, then generate a web page saying "I'm sorry, but I can't find the word 'banana'". It would send the web page to his browser, which would then parse the page and display it.
Now suppose that, instead of entering "banana" as the search phrase, the user entered something like "banana ‹SCRIPT› ‹Alert('Hello');› ‹/SCRIPT›". If the search feature were written to blindly use whatever search phrase it's provided, it would search for the entire string, and create a web page saying "I'm sorry, but I can't find the word "banana ‹SCRIPT› ‹Alert('Hello');› ‹/SCRIPT›"". However, all of the text beginning with "‹SCRIPT›" and ending with "‹/SCRIPT›" is actually program code, so when the page was processed, a dialogue box would be displayed by the user's browser, saying "Hello".
So far, this example has only shown how a user could "relay" code off a web server and make it run on his own machine. That's not a security vulnerability. However, it's possible for a malicious web site operator to invoke this vulnerability to run on the computer of a user who visits his site. If Web Site B were operated by a malicious user who was able to entice the user into visiting it and clicking a hyperlink, Web Site B could go to Web Site A, fill in the search page with malicious script, and submit it on behalf of the user. The resulting page would return to the user (since the user, having clicked on the hyperlink, was ultimately the requester), and process on the user's machine.

What could the script do on the user's machine?
The script from Web Site B (the attacker's site) would run on the user's machine as though it had come from Web Site A. In practical terms, this would mean two things:

• It would run using the security settings on the user's machine that were appropriate to Web Site A.
• The script from Web Site B would be able to access cookies and any other data on the user's system that belonged to Web Site A.

Would it matter what browser the user was using?
No. The important point here is that the problem lies with the software on the web server, not with the browser. The vulnerability could potentially occur anytime software on the web server blindly uses whatever inputs it's provided. Instead, it should filter out any inputs that aren't appropriate. In the example above, the search engine should strip out any characters that could be used to inject script into the search process, such as "". A full description of the characters that should be filtered is available in Knowledge Base article Q252985.

What's wrong with IIS?
Three services provided by IIS don't properly filter their inputs, and as a result could be used in a cross-site scripting attack. The services are:

• A search facility that allows IIS help files to be searched. The facility is only provided in IIS 5.0 and 5.1, so only these versions are affected by the vulnerability.
• A message that's returned when someone requests a web page that's been moved to a new location. (Such a message is known as a redirect response). The versions of this message that are produced by IIS 4.0, 5.0 and 5.1 are affected by the vulnerability. However, a successful attack could only be carried out via this message if the target of the attack was running a browser other than Internet Explorer.
• Several error messages that are returned when a user's request for a web page results in an error. The default versions of these messages produced in IIS 4.0 and 5.0 are affected by the vulnerability.

What would these vulnerabilities enable an attacker to do?
The vulnerabilities would allow an attacker who operated a web site and was able to lure another user into clicking a link on it to carry out a cross-site scripting attack via another web site that was running IIS. As discussed above, this would enable the attacker to run script in the user's browser using the security settings of the other web site (the one running IIS), and to access cookies and other data belonging to it.

You said above that one of the vulnerabilities could only be exploited if the user was using a browser other than IE. Why is this?
In the case of the error message that's returned when a web page has been moved, IE doesn't actually display the text in the error message. Instead, it processes information elsewhere in the server's response and immediately takes the user to the new page. As a result, it's not susceptible to the cross-site scripting error. Other browsers may or may not work similarly, depending on how they implement the handling of redirect responses.

Does this vulnerability provide any way for the attacker to harm my web site?
No. The attacker couldn't take any action against your site, but would be able to use your site as an unwitting accomplice in an attack against people who may visit your site.

You said that the point of the attack would be for the attacker to get script running in the user's browser using the security settings of my web site. What specific capabilities would the attacker gain by doing this?
It would vary from site to site, based on what Security Zone the attacker's site and yours were placed in.

• If they were both in the same zone (and by default, all web sites reside in the Internet Zone unless the user moves them), they would both be subject to exactly the same security restrictions and the attacker would gain nothing through the vulnerability.
• If the user had put the attacker's site into a more restricted zone than yours, the attacker would gain the ability for his script to do anything on the user's computer that script from your site could do.
• If the user had put your site into a more restricted zone than yours, the attacker would actually lose capabilities through the attack.

It's important to note, however, that regardless of the security settings, the attacker's script would always be able to access cookies and any other data on the user's system belonging to the third-party site. This is because, as far as the browser can tell, the attacker is the third-party site.

How does the patch eliminate the vulnerability?
The patch eliminates the vulnerability by ensuring that both of the services discussed above properly filter their inputs before using them.

Download locations for this patch

• Microsoft IIS 4.0:
  • Windows NT 4.0 Workstation, Windows NT 4.0 Server, or Windows NT 4.0 Server, Enterprise Edition:

    http://www.microsoft.com/Downloads/details.aspx?displaylang=en&FamilyID=7DD8F695-FA97-4378-B57B-7BCCF3533BE3

  • Windows NT 4.0 Server, Terminal Server Edition:

    Included in the Windows NT Server 4.0, Terminal Server Edition Security Rollup Package

• Microsoft IIS 5.0:

  http://www.microsoft.com/Downloads/details.aspx?displaylang=en&FamilyID=7DD8F695-FA97-4378-B57B-7BCCF3533BE3

• Microsoft IIS 5.1:

  http://www.microsoft.com/downloads/details.aspx?FamilyID=c87bad03-a4b8-4199-8259-8a37af61ef63&DisplayLang=en