• Article

Security Bulletin

Microsoft Security Bulletin MS03-018 - Important

Cumulative Patch for Internet Information Service (811114)

Published: May 28, 2003 | Updated: May 30, 2003

Version: 1.1

Originally posted: May 28, 2003
Updated: May 30, 2003

Summary

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

Impact of vulnerability: Allow an attacker to execute code of their choice

Maximum Severity Rating: Important

Recommendation: Customers hosting web servers using Microsoft® Windows NT® 4.0, Windows® 2000, or Windows® XP should install the patch at the earliest opportunity.

Affected Software:

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

Non Affected Software:

  • Microsoft Internet Information Services 6.0

End User Bulletin: An end user version of this bulletin is available at: https:.

General Information

Technical details

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 since Windows 2000 Service Pack 2 and IIS 5.1. A complete listing of the patches superseded by this patch is provided below, in the section titled "Additional information about this patch".

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

  • A Cross-Site Scripting (CSS) vulnerability affecting IIS 4.0, 5.0 and 5.1 involving the error message that's returned to advise that a requested URL has been redirected. An attacker who was able to lure a user into clicking a link on his or her 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.
  • A buffer overrun that results because IIS 5.0 does not correctly validate requests for certain types of web pages known as server side includes. An attacker would need the ability to upload a Server-side include page to a vulnerable IIS server. If the attacker then requested this page, a buffer overrun could result, which would allow the attacker to execute code of their choice on the server with system-level permissions.
  • A denial of service vulnerability that results because of a flaw in the way IIS 4.0 and 5.0 allocate memory requests when constructing headers to be returned to a web client. An attacker would need the ability to upload an ASP page to a vulnerable IIS server. This ASP page, when called by the attacker, would attempt to return an extremely large header to the calling web client. Because IIS does not limit the amount of memory that can be used in this case, this could case IIS to fail as a result of running out of local memory.
  • A denial of service vulnerability that results because IIS 5.0 and 5.1 do not correctly handle an error condition when an overly long WebDAV request is passed to them. As a result an attacker could cause IIS to fail - however both IIS 5.0 and 5.1 will by default restart immediately after this failure.

There is a dependency associated with this patch - it requires the patch from Microsoft Security Bulletin MS02-050 to be installed. If this patch is installed and MS02-050 is not present, client side certificates will be rejected. This functionality can be restored by installing the MS02-050 patch.

Mitigating factors:

Redirection Cross Site Scripting:

  • IIS 6.0 is not affected.
  • The vulnerability 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 target page must be an ASP page, which uses Response.Redirect to redirect the client, to a new URL that is based on the incoming URL of current request.

Server Side Include Web Pages Buffer Overrun

  • IIS 4.0, IIS 5.1 and IIS 6.0 are not affected.
  • The IIS Lockdown tool by default disables the ssinc.dll mapping, which will block this attack.
  • An attacker must have the ability to upload files to the IIS Server.

ASP Headers Denial of Service

  • An attacker must have the ability to upload files to the IIS server.
  • IIS 5.0 will automatically restart after failing.
  • IIS 5.1 and IIS 6.0 are not affected.

WebDAV Denial of Service

  • IIS 6.0 is not affected.
  • IIS 5.0 and 5.1 will restart automatically after this failure.
  • The IIS Lockdown tool disables WebDAV by default, which will block this attack.

Severity Rating:

Redirection Cross Site Scripting
IIS 4.0 Low
IIS 5.0 Low
IIS 5.1 Low

Server Side Include Web Pages Buffer Overrun
IIS 4.0 None
IIS 5.0 Moderate
IIS 5.1 None

ASP Headers Denial of Service
IIS 4.0 Moderate
IIS 5.0 Moderate
IIS 5.1 None

WebDAV Denial of Service
IIS 4.0 None
IIS 5.0 Important
IIS 5.1 Important

Aggregate Severity of all Vulnerabilities
IIS 4.0 Moderate
IIS 5.0 Important
IIS 5.1 Important

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:

Redirection Cross Site Scripting CAN-2003-0223

Server Side Include Web Pages Buffer Overrun CAN-2003-0224

ASP Headers Denial of Service CAN-2003-0225

WebDAV Denial of Service CAN-2003-0226

Tested Versions:

Microsoft tested IIS 4.0, 5.0, 5.1 and 6.0 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.

Frequently asked questions

What versions of Windows does Internet Information Services 6 ship with?
IIS 6 ships with Windows Server 2003. It is not affected by any of the vulnerabilities described in this security bulletin.

Redirection Cross Site Scripting (CAN-2003-0223)

What's the scope of this vulnerability?
This is a cross-site scripting vulnerability that could allow 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.

What is redirection?
Redirection happens when a web browser makes a request for a web page that doesn't exist and the web server redirects the browser to another page such as a generic error page or the website's homepage. For example, the webpage </https:>https: does not exist, but instead of providing an error, the web server redirects the browser to a page that suggests pages that the user may have been looking for as well as providing a site map. This process is redirection.

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

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.

What causes the vulnerability?
The vulnerability results because the ASP function responsible for redirection displays the URL in HTML text without proper encoding.

What's wrong with IIS Redirection?
The ASP function responsible for redirection does not correctly encode the URL for displaying in HTML text. As a result it is possible to embed script in a redirection request and cause this to be returned to the web browser.

What would this vulnerability enable an attacker to do?
The vulnerability 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. However, most browsers will automatically follow the redirection response header and skip the HTML text. The client is not vulnerable in this case.

How could an attacker exploit this vulnerability?
To exploit the vulnerability an attacker would need to host a webpage and lure a user to click on a link in that page, or would need to send the user a URL in an e-mail. This URL would need to contain script. It would also need to point to a web page on the vulnerable IIS Server that did not exist - when the IIS redirection function handled the redirection of the non-existent page, it would pass the attacker's script back to the browser.

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 script is not passed during an IIS redirection request.

SSINC Buffer Overrun (CAN-2003-0224)

What's the scope of this vulnerability?
This is a buffer overrun vulnerability. It could allow an attacker to execute code of their choice with system-level permissions on the IIS Server.

What causes the vulnerability?
The vulnerability results because IIS does not correctly check parameters when responding to requests for Server-side Include (SSINC) pages such as .shtml, .stm and .shtm files.

What's wrong with the way IIS responds to requests for static web pages?
There is a flaw in the component responsible for serving static web pages. The component does not correctly validate requests passed to it and as a result a buffer overrun condition occurs when overly long requests are passed to it.

What could this vulnerability enable an attacker to do?
This vulnerability could enable an attacker to execute code of their choice with system-level privileges on the IIS Server. However to do so, an attacker would need to be able to first upload SSINC web pages to the IIS Server.

Does the IIS Lockdown Tool block this attack?
Yes - by default the IIS Lockdown tool will remove the SSINC script map.

How could an attacker exploit this vulnerability?
An attacker could seek to exploit this vulnerability by uploading a specially named SHTML web page to the IIS Server - the attacker would need explicit permissions to do this. The attacker would also need to have an understanding of the directory structure on the web server. If the attacker then requested this webpage, a buffer overrun would occur that could allow him or her to execute code of their choice.

What does the patch do?
The patch eliminates the vulnerability by ensuring that the affected IIS component correctly validates input passed to it.

ASP Headers Denial of Service (CAN-2003-0225)

What's the scope of this vulnerability?
This is a denial of service vulnerability that could allow an attacker to cause IIS to fail. IIS 5.0 would restart automatically; IIS 4.0 would need to be restarted manually.

What causes the vulnerability?
The vulnerability results because the ASP function Response.AddHeader does not place a limit on the size of the header that is returned to a browser. As a result it is possible for an maliciously crafted ASP page to generate an overly large header that exceeds the memory available to IIS, causing it to fail.

What's wrong with the way headers are generated by IIS?
The flaw is not in the way IIS actually generates headers, but in the fact that it does not place a limit on the size of the header that can be generated. As a result, it is possible to cause a header to be generated that is so large that it exhausts the memory available to IIS, causing it to fail.

What could this vulnerability allow an attacker to do?
This could allow an attacker to cause IIS to fail and therefore stop serving web pages. It is worth noting that IIS 5.0 would automatically restart, so the Denial of Service would be temporary. IIS 4.0 would require manual restarting.

How could an attacker exploit this vulnerability?
An attacker would need to be able to upload a malicious ASP file to the IIS Server - this malicious ASP would contain code that would cause an overly large header to be generated when the page was requested. If the attacker then request the page, the code would execute, which could cause IIS to fail as a result of excessive memory being required to complete the request. It should be noted that an attacker must have permissions to upload ASP files to the server in order for him or her to carry out an attack based on this vulnerability.

What does the patch do?
The patch places a restriction on the size of the return header that can be generated.

WebDAV Denial of Service (CAN-2003-0226)

What's the scope of this vulnerability?
This is a denial of service. It could allow an attacker to cause a temporary denial of service in IIS 5.0 and 5.1.

What causes the vulnerability?
The vulnerability is caused by a flaw in the way overly long WebDAV requests that contain XML commands are handled. The flaw results because it is possible for the error handling sequence to get out of order when handling a particular type of XML error, which causes IIS to fail.

What's wrong with the WebDAV errors are handled?
It's possible for an overly long WebDAV request to cause the error handling for XML requests to get out of sequence. This causes IIS to fail, however both IIS 5.0 and 5.1 will automatically restart. What could this vulnerability allow an attacker to do? This could allow an attacker to cause IIS 5.0 or 5.1 to fail and therefore stop serving web pages. Both IIS 5.0 and 5.1 would automatically restart.

How could an attacker exploit this vulnerability?
An attacker could exploit this vulnerability by sending an overly long WebDAV request that contained malformed XML data to an IIS 5.0 or 5.1 web server. This could cause the error handling for the malformed XML to become out of sequence, causing IIS to fail.

What does the patch do?
The patch corrects the vulnerability by enforcing the correct error handling sequence when handling malformed XML data.

Does this patch have any dependencies on other patches?
Yes - it requires the patch from Microsoft Security Bulletin MS02-050 to be installed. If this IIS cumulative patch is installed and MS02-050 is not present, client side certificates will be rejected. This functionality can be restored by installing the MS02-050 patch either before or after installing the IIS Cumulative patch.

Patch availability

Download locations for this patch

Download locations for this patch

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 2 or Service Pack 3.
  • The IIS 5.1 patch can be installed on systems running Windows XP Professional Gold and Service Pack 1.

Inclusion in future service packs:

  • No additional service packs are planned for Windows NT 4.0.
  • The IIS 5.0 fixes will be included in Windows 2000 Service Pack 4.
  • The IIS 5.1 fixes will be included in Windows XP Service Pack 2.

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 Q327696 provides additional information on this procedure.
  • IIS 5.0: In most cases, the patch does not require a reboot. The installer stops the needed services, applies the patch, then restarts them. However, if the needed services cannot be stopped for any reason, it will require a reboot. If this occurs, a prompt will be displayed advising of the need to reboot.
  • IIS 5.1: No. (In some cases, a pop-up dialogue may say that the system needs to be rebooted in order for the patch installation process to be completed. This dialogue, if it appears, can be ignored)

Patch can be uninstalled: Yes

Superseded patches:

This patch supersedes the ones provided in the following Microsoft Security Bulletins:

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\Q811114.

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

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\Q811114.

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

IIS 5.1:

  • 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 XP\SP2\Q811114.

  • 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 XP\SP2\Q811114\Filelist.

Caveats:

  1. This patch requires the patch from Microsoft Security Bulletin MS02-050 to be installed. If this IIS cumulative patch is installed and MS02-050 is not present, client side certificates will be disabled. This functionality can be restored by installing the MS02-050 patch either before or after installing the IIS Cumulative patch.

  2. The fixes for four vulnerabilities affecting IIS 4.0 servers are not included in the patch, because they require administrative action rather than a software change. Administrators should ensure that in addition to applying this patch, they also have taken the administrative action discussed in the following bulletins:

    • Microsoft Security Bulletin MS00-028
    • Microsoft Security Bulletin MS00-025
    • Microsoft Security Bulletin MS99-025 (which discusses the same issue as Microsoft Security Bulletin MS98-004)
    • Microsoft Security Bulletin MS99-013

  3. The patch does not include fixes for vulnerabilities involving non-IIS products like Front Page Server Extensions and Index Server, even though these products are closely associated with IIS and typically installed on IIS servers. At this writing, the bulletins discussing these vulnerabilities are:

    There is, however, one exception. The fix for the vulnerability affecting Index Server which is discussed in Microsoft Security Bulletin MS01-033 is included in this patch. We have included it because of the seriousness of the issue for IIS servers.

  4. Customers using IIS 4.0 should ensure that they have followed the correct installation order before installing this or any security patch. Specifically, customers should ensure that Windows NT 4.0 Service Pack 6a has been applied (or re-applied) after installing the IIS 4.0 service.

  5. Customers using Site Server should be aware that a previously documented issue involving intermittent authentication errors has been determined to affect this and a small number of other patches. Microsoft Knowledge Base article Q317815discusses the issue and how resolve it.

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 the following for reporting these issues to us and working with us to protect customers:

  • </https:>https: for reporting the Redirection Cross Site Scripting and WebDAV Denial of Service vulnerability.
  • Mark Litchfield of Next Generation Security Software Ltd and </https:>https: for reporting the WebDAV Denial of Service vulnerability.
  • NSFocus for reporting the Server Side Include Web Pages Buffer Overrun vulnerability.

Support:

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 (May 28, 2003): Bulletin Created.
  • V1.1 (May 30, 2003): Updated to correctly reflect that Server Side Include Web Pages Buffer Overrun (CAN-2003-0224)vulnerability would give an attacker system-level permissions.

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