Reported April 10, 2002, by Microsoft.
Microsoft Internet Information Services 5.1
Microsoft Internet Information Services 5.0
Microsoft Internet Information Server 4.0
Multiple vulnerabilities exist in Microsoft’s IIS that can result in server compromise or a Denial of Service (DoS) condition. The first vulnerability is a buffer overrun that involves the operation of the chunked encoding transfer mechanism using Active Server Pages (ASP) in IIS 5.0 and 4.0. An attacker can exploit this vulnerability to to overrun the system's heap memory, causing the IIS service to fail or letting code run on the server.
The second vulnerability is a Microsoft-discovered problem related to the preceding vulnerability, but that lies elsewhere in the ASP data-transfer mechanism. An intruder can exploit the vulnerability in a similar manner as the preceding vulnerability with the same scope but affecting IIS 5.1, 5.0, and 4.0.
A third vulnerability involves a buffer overrun that affects how IIS 5.1, 5.0, and 4.0 process HTTP-header information in certain cases. IIS performs a safety check before parsing the fields in HTTP headers to ensure that expected delimiter fields are present and in reasonable places. However, an attacker can spoof the check and convince IIS that the delimiters are present even when they're not. An attacker can use this vulnerability to create a URL whose HTTP-header field values overrun a processing buffer.
A fourth buffer overrun vulnerability in IIS 5.1, 5.0, and 4.0 that Microsoft discovered results from a safety-check error that IIS performs during server-side includes. In some cases, IIS properly processes a user request for a Web page by including the file in an ASP script and processing it. Before processing the include request, IIS performs an operation on the user-specified filename to ensure that the filename is valid and sized appropriately to fit in a static buffer. However, in some cases, an attacker can provide a bogus, extremely long filename in a way that passes the safety check and causes a buffer overrun.
A fifth buffer overrun that affects the HTR Internet Server API (ISAPI) extension in IIS 5.0 and 4.0. By sending a series of specially malformed HTR requests, an intruder can cause the IIS service to fail or cause code to run on the server.
A sixth vulnerability involves the way IIS 5.1, 5.0, and 4.0 handles error conditions from ISAPI filters and causes a DoS condition. At least one ISAPI filter (which ships as part of FrontPage Server Extensions and asp.net), and possibly other filters, generates an error when a user sends a request containing an URL that exceeds the maximum length that the filter set. In processing this error, the filter replaces the URL with a null value. A vulnerability results because IIS attempts to process the URL when sending the error message back to the requester, resulting in an access violation that causes the IIS service to fail.
A seventh vulnerability, causing a DoS condition, involves the way the FTP service in IIS 5.1, 5.0, and 4.0 handles a request for the status of the current FTP session. If an attacker establishes an FTP session with an affected server and imposes a status request that creates a particular error condition, a vulnerability in the FTP code prevents IIS from correctly reporting the error. Instead, other code within the FTP service attempts to use uninitialized data, which causes an access violation. The disruption of service affects FTP and Web services.
The final three vulnerabilities are new cross-site scripting vulnerabilities affecting IIS 5.1, 5.0, and 4.0: one involves the results page that IIS returns when searching the IIS Help files; one involves HTTP error pages; and one involves the error message that IIS returns to advise the user of a redirected URL request. These three vulnerabilities have the same scope and effect: an attacker who can lure a user into clicking a link on a certain Web site can relay a request containing script and send the request to a third-party Web site running IIS, sending the third-party site’s response (still including the script) to the user. The script then renders in the browser using the security settings of the third-party site rather than the attacker’s site