Microsoft Security Bulletin MS02-023

Technical description:

This is a cumulative patch that includes the functionality of all previously released patches for IE 5.01, 5.5 and 6.0. In addition, it eliminates the following six newly discovered vulnerabilities:

• A cross-site scripting vulnerability in a Local HTML Resource. IE ships with several files that contain HTML on the local file system to provide functionality. One of these files contains a cross-site scripting vulnerability that could allow a script to execute as if it were run by the user herself, causing it to run in the local computer zone. An attacker could craft a web page that exploits this vulnerability and then either host that page on a web server or send it as HTML email. When the web page was viewed and the attacker's script run, the attacker's script would be injected into the local resource, where it would run in the Local Computer zone, allowing it to run with fewer restrictions than it would in the Internet Zone.
• An information disclosure vulnerability related to the use of am HTML object provides that support for Cascading Style Sheets that could allow an attacker to read, but not add, delete or change, data on the local system. An attacker could craft a web page that exploits this vulnerability and then either host that page on a web server or send it as HTML email. When the page was viewed, the element would be invoked. Successfully exploiting this vulnerability, however, requires exact knowledge of the location of the intended file to be read on the user's system. Further, it requires that the intended file contain a single, parcicular ASCII character.
• An information disclosure vulnerability related to the handling of script within cookies that could allow one site to read the cookies of another. An attacker could build a special cookie containing script and then construct a web page that would deliver that cookie to the user's system and invoke it. He could then send that web page as mail or post it on a server. When the page executed and invoked the script in the cookie, it could potentially read or alter the cookies of another site. Successfully exploiting this, however, would require that the attacker know the exact name of the cookie as stored on the file system to be read successfully.
• A zone spoofing vulnerability that could allow a web page to be incorrectly reckoned to be in the Intranet zone or, in some very rare cases, in the Trusted Sites zone. An attacker could construct a web page that exploits this vulnerability and attempt to entice the user to visit the web page. If the attack were successful, the page would be run with fewer security restrictions than is appropriate.
• Two variants of the "Content Disposition" vulnerability discussed in Microsoft Security Bulletin MS01-058 affecting how IE handles downloads when a downloadable file's Content-Disposition and Content-Type headers are intentionally malformed. In such a case, it is possible for IE to believe that a file is a type safe for automatic handling, when in fact it is executable content. An attacker could seek to exploit this vulnerability by constructing a specially malformed web page and posting a malformed executable file. He could then post the web page or mail it to the intended target. These two new variants differ from the original vulnerability in that they for a system to be vulnerable, it must have present an application present that, when it is erroneously passed the malformed content, chooses to hand it back to the operating system rather than immediately raise an error. A successful attack, therefore, would require that the attacker know that the intended victim has one of these applications present on their system.

Finally, it introduces a behavior change to the Restricted Sites zone. Specifically, it disables frames in the Restricted Sites zone. Since the Outlook Express 6.0, Outlook 98 and Outlook 2000 with the Outlook Email Security Update and Outlook 2002 all read email in the Restricted Sites zone by default, this enhancement means that those products now effectively disable frames in HTML email by default. This new behavior makes it impossible for an HTML email to automatically open a new window or to launch the download of an executable.

Mitigating factors:

Cross-Site Scripting in Local HTML Resource:

• Outlook 98 and 2000 (after installing the Outlook Email Security Update), Outlook 2002, and Outlook Express 6 all open HTML mail in the Restricted Sites Zone. As a result, customers using these products would not be at risk from automated email-borne attacks. However, these customers can still be attacked if they choose to click on a hyperlink in a malicious HTML email.
• Customers using Outlook 2002 SP1 who have enabled the "Read as Plain Text" feature would be immune from the HTML email attack. This is because this feature disables all HTML elements, including scripting, from mail when it is displayed.
• Any limitations on the rights of the user's account would also limit the actions of the attacker's script.
• Customers who exercise caution in what web sites they visit or who place unknown or untrusted sites in the Restricted Sites zone can potentially protect themselves from attempts to exploit this issue on the web.

Local Information Disclosure through HTML Object:

• It can only be used to read information. It cannot add, change or delete any information.
• The attacker would need to know the exact name and location on the system of any file they attempted to read.
• Only files that contained a particular, individual ASCII character could be read. If this single character is not present, the attempt to read the file would fail.
• Outlook 98 and 2000 (after installing the Outlook Email Security Update), Outlook 2002, and Outlook Express 6 all open HTML mail in the Restricted Sites Zone. As a result, customers using these products would not be at risk from automated email-borne attacks. However, these customers can still be attacked if they choose to click on a hyperlink in a malicious HTML email.
• Customers using Outlook 2002 SP1 who have enabled the "Read as Plain Text" feature would be immune from the HTML email attack. This is because this feature disables all HTML elements, including scripting, from mail when it is displayed.

Script within Cookies Reading Cookies:

• The specific information an attacker could access would depend on what information a site has chosen to store in its cookies. Best practices strongly recommend against storing sensitive information in cookies.
• Mounting a successful attack requires that the attacker know the exact name and location of the target cookie. This vulnerability provides no means for an attacker to acquire that information.
• Outlook 98 and 2000 (after installing the Outlook Email Security Update), Outlook 2002, and Outlook Express 6 all open HTML mail in the Restricted Sites Zone. As a result, customers using these products would not be at risk from automated email-borne attacks. However, these customers can still be attacked if they choose to click on a hyperlink in a malicious HTML email.
• Customers using Outlook 2002 SP1 who have enabled the "Read as Plain Text" feature would be immune from the HTML email attack. This is because this feature disables all HTML elements, including scripting, from mail when it is displayed.

Zone Spoofing through Malformed Web Page:

• A successful attack would require NetBIOS connectivity between the user and the attacker's site. Any filtering of NetBIOS, such as that found by ISP's or at the firewall perimeter, would thwart attempts to exploit this vulnerability.
• Any attempt to render a web site in the Trusted Sites zone would require very specific knowledge of custom configuration made by the user. This aspect of the vulnerability is not exploitable by default, nor does the vulnerability give the means to acquire the necessary information for that attack.

New Variants of the "Content Disposition" Vulnerability:

• Any successful attempt to exploit this vulnerability requires that the attacker know that the intended target have specific versions of specific applications on their system. The vulnerability gives no means for an attacker to know what applications or versions are present on the system.
• Any attempt to exploit the vulnerability requires that the attacker host a malicious executable on a server accessible to the intended victim. If the hosting server is unreachable for any reason, such as DNS blocking or the server being taken down, the attack would fail.

Severity Rating:

Cross-Site Scripting in Local HTML Resource:

Local Information Disclosure through HTML Object:

Script within Cookies Reading Cookies:

Zone Spoofing through Malformed Web Page:

New Variants of the "Content Disposition" Vulnerability:

Aggregate severity of all vulnerabilities eliminated by patch:

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. The personal information disclosure vulnerabilities are most likely to affect client systems, based on usage patters. The variants of the "Content Disposition" vulnerability require knowledge of the software installed on a system by the user. The Zone Spoofing vulnerability requires NetBIOS access, which is commonly blocked at the perimeter firewall and by ISP's. The aggregate severity includes the severity of vulnerabilities announced in previously released security bulletins.

Vulnerability identifiers:

• Cross-Site Scripting in Local HTML Resource: CAN-2002-0189
• Local Information Disclosure through HTML object: CAN-2002-0191
• Script within Cookies Reading Cookies: CAN-2002-0192
• Zone Spoofing through Malformed Web Page: CAN-2002-0190
• "Content Disposition" Variants: CAN-2002-0193, CAN-2002-0188

Tested Versions:

The following table indicates which of the currently supported versions of Internet Explorer are affected by the vulnerabilities. Versions of IE prior to 5.01 Service Pack 2 are no longer eligible for hotfix support. IE 5.01 SP2 is supported only via Windows® 2000 Service Packs and Security Roll-up Packages and on Windows NT® 4.0.

What vulnerabilities are eliminated by this patch?
This is a cumulative patch that, when applied, eliminates all previously addressed security vulnerabilities affecting Internet Explorer 5.01, 5.5 and 6.0. In addition to eliminating all previously discussed vulnerabilities versions, it also eliminates eliminates six new ones:

• A vulnerability that could allow an attacker to cause script to be run in the Local Computer Zone.
• A vulnerability that could disclose information store on the local system to an attacker including, potentially, personal information.
• A vulnerability that could allow a web site to read the cookies of another web site by embedding script in cookies on the local system and invoking that script to read other cookies on the local system.
• A vulnerability that could allow an attacker to cause a web page's security zone settings to be incorrectly determined and allow a page to run with fewer security restrictions than is appropriate.
• Two newly discovered variants of the "Content-Disposition" vulnerability first discussed in MS01-051.

Finally, it introduces a new enhancement to the Restricted Sites zone. Specifically, it disables frames in the Restricted Sites zone.

Cross-Site Scripting in Local HTML Resource (CVE-CAN-2002-0189):

What's the scope of the first vulnerability?
This is a cross-site scripting vulnerability that can lead to an elevation of privilege. An attacker who was able to successfully exploit this vulnerability could cause HTML scripts to execute as if they were run locally on the user's system. As a consequence, the scripts could take any action on the local system as if it were run locally.
An attacker could seek to exploit this vulnerability by crafting a malicious web page. He could then either post the page on a web site or send it as an HTML email. The vulnerability would then be exploited when the user displayed the malicious web page. In the case where the page was posted on an attacker's site, this would happen when the user navigated to the site. In the case of HTML email, this would happen when either the user opens the email or it displayed in a preview pane. If a user were reading email in the Restricted Sites zone, however, the attack would only succeed if the user were enticed to click an HTML link. Any restrictions on the user's ability to take actions on the local system would limit the actions of an attacker's script. In addition, customers who read mail in the Restricted Sites Zone would be immune from attempts to automatically exploit this by HTML email.

What causes the vulnerability? 
The vulnerability results because a local resource file that is included with IE contains an HTML web page that fails to properly validate inputs.

What is a "local resource file" in IE? 
Some of the functionality that a user sees in IE is actually provided by HTML resources that are stored on the local file system. Examples of pages like this include error messages that are raised when a site is unreachable. The information that actually makes up the page is a standard HTML web page, but is stored on the local file system, rather than being sent from a remote server.

What is Cross-Site Scripting 
Cross-Site Scripting is a vulnerability that can allow script to be injected into a user's session with a web site.
By injecting code into the domain of another web site, an attacker can cause script of his choice to execute as if it were part of that web site's domain.

What could this vulnerability enable an attacker to do? 
This vulnerability could allow an attacker to invoke the local HTML resource and inject script into the page as it is called. As the page is rendered, the attacker's script would then be rendered as if it had been called by the page itself. Because this particular HMTL page is on the local system, this allows the attackers script to run in the Local Computer zone. This has the effect of allowing the attacker's script to run as if the user had chosen to run it herself.
For example, if the user had permissions to change the security setting of IE, the attacker's script could make the same changes. Conversely however, this also means that any limitations on the user's privileges would also constrain the attacker's script. If a user were prohibited from changing their IE security settings, for instance, the script too would be unable to make those changes.

How could an attacker exploit this vulnerability? 
An attacker could seek to exploit this vulnerability by creating a specially crafted web page that invoked the vulnerable web page and injected the script he wanted to execute into the vulnerable web page. When the page loaded the script would execute in the Local Computer zone.
An attacker could attempt to levy this attack in one of two ways: He could post the web page on a server, or send it to the intended user as an HTML email.

What are the risks posed by the web-borne attack vector? 
From the attacker's point of view, the web-borne attack vector has the advantage that all Internet Web sites reside in the "Internet Zone", which enables scripting. This means that unless a user were making judicious use of the "Restricted Sites zone" and had placed the attacker's site in that zone, she would be vulnerable when she visited the attacker's site.
However, the disadvantage of this attack vector for the attacker is that this scenario requires social engineering to make the user choose to visit his site. A user who exercised caution in her choice of web sites would successfully avoid attempts to exploit this vulnerability altogether. Also, as noted earlier, if a user visits an unknown or untrusted site and places that site in the Restricted Sites zone, she would successfully thwart the attack.

What are the risks posed by the email-borne attack vector? 
The advantage of an email-borne attempt to exploit this vulnerability is that it requires no social engineering to lure the user to a web site: the attacker can send the malicious page directly to the user. Because of this, this also makes it easier for an attacker to attempt to attack a large number of users: he can send the same web page to as many users as he wanted.
The disadvantage to this attack, though, is that the success of this attack would depend on the configuration of the mail client. If a user's mail client has been configured to read mail in the Restricted Sites zone, attempts to exploit this vulnerability through email would fail. This is because scripting is disabled by default in the Restricted Sites zone. Customers who are using Outlook Express 6.0, Outlook 98 and Outlook 2000 with the Outlook Email Security Update and Outlook 2002 would thus be protected in a default installation, because those products all read mail in the Restricted Sites zone. In addition, customers who are using the new "Read as Plain Text" feature would also be protected against this attack vector. This is because the "Read as Plain Text" feature strips all HTML features, including scripts, from HTML email.

I'm using one of the email products and/or the new "Read as Plain Text" feature you mentioned above. Does that mean I don't need the patch? 
While these products and this feature can all protect you against the email-borne attack, you should still apply the patch to ensure that you're protected against the web-borne scenario. In addition, this patch eliminates other vulnerabilities, some of which are not thwarted by the OESU.

What does the patch do? 
The patch eliminates the vulnerability by instituting proper input validation in the local HTML resource in question.

Local Information Disclosure through HTML Object (CAN-2002-0191):

What's the scope of the second vulnerability?
This is an information disclosure vulnerability. An attacker who successfully exploited this vulnerability would be able to view files on the user's local computer.
An attacker could attempt to exploit this vulnerability by building a web page that contained the specific object. In constructing the page, he would have to specify the name and location of the file he wished to read. He could then either send the page as an HTML email, or post it on a site under his control.
This particular vulnerability is subject to a number of significant mitigating factors:

• It can only be used to read information. It cannot add, change or delete any information.
• The attacker would need to know the exact name and location on the system of any file they attempted to read.
• Only files that contained a particular, individual ASCII character could be read. If this single character is not present, the attempt to read the file would fail.
• The vulnerability requires that scripting be enabled. If the web page were viewed within the Restricted Sites zone, the vulnerability could not be exploited. Any web page viewed in the Restricted Sites zone, or mail read in the Restricted Sites zone would be unable to exploit this vulnerability.
• Outlook Express 6.0, Outlook 98 and Outlook 2000 with the Outlook Email Security Update and Outlook 2002 all read mail in the Restricted Sites zone by default and would be immune from HTML email attack.
• Finally, customers using Outlook 2002 SP1 who have enabled the "Read as Plain Text" feature would be immune from the HTML email attack.

What causes the vulnerability? 
The vulnerability results because of incorrect handling when a particular HTML object that provides support for Cascading Style Sheets invokes a file on the local system. The object in question can incorrectly return information to the remote web site from the local file system.

What are Cascading Style Sheets? 
Cascading Style Sheets (CSS) is an HTML specification that enables a web site to easily develop pages with a consistent visual style.
Support for Cascading Sytle Sheets is implemented in IE by making available a series of HTML elements and objects. Each of these elements and objects make it possible for a web site to take advantage of CSS. For example, it is possible for a web site to use the text alingment and color elements to have text in a web page be centered and colored red.

What's wrong with the HTML object in question? 
When the particular HTML object is invoked and referred to a file on the local system, the directive returns information from the local file. It should deny access to that local resource.

What could this vulnerability enable an attacker to do? 
This vulnerability could allow an attacker to gather information stored on the local system, possibly including information of a personal nature. This, however, would require that the information in question be stored in a well-known location on the user's system.

How could an attacker exploit this vulnerability? 
An attacker could seek to exploit this vulnerability by creating a web page that invoked the HTML objection in question. The object would have to contain a call to the exact file name and location on the intended victim's system. If the file in question contained the particular character in question, the attack would succeed.
An attacker could attempt to levy this attack in one of two ways: He could post the web page on a server, or send it to the intended user as an HTML email.

You've said this requires a particular character to succeed, what does that mean? 
The HTML object in question is only able to read information that is formatted in a particular manner and that formatting is indicated by the presence of a particular ASCII character.
This means that if an attacker calls to a file on the local system, but that file does not contain this particular character within it, the attack would fail and would not return any information.

What are the risks posed by the web-borne attack vector? 
As noted above, the web-borne attack vector has the advantage of all Internet Web sites residing in the "Internet Zone", where scripting is enabled. However, a successful attack would require luring the user to the attacker's site.

What are the risks posed by the email-borne attack vector?
The risks posted by the email-borne attack are similar to those noted above. The attacker could simply choose to mail the malicious web page to one or several users. As above, however, attacks mounted against users who read mail in the Restricted Sites zone would fail.

How does the patch eliminate the vulnerability? 
The patch eliminates the vulnerability by implementing proper handling of the HTML object in question when it makes calls to files on the local system.

Script within Cookies Reading Cookies: CVE-CAN-2002-0192:

What's the scope of the third vulnerability?
This is an information disclosure vulnerability. Through scripting, a malicious web site could potentially read or alter the information stored by other web sites on the local system, which could contain personal information.
In seeking to exploit this vulnerability the attacker would most likely have to create a web page that created a specially formed cookie containing script. The attacker would then either post the page on a site under their control or send it as an HTML email.
The vulnerability does not allow script to access any other information on the local system. It also does not allow scripting to be run to take any other actions on the system, such as adding, changing, or deleting data. Finally, an attacker would have to know the exact name of the cookie he wished to access. In itself, this vulnerability provides no means for an attacker to acquire that information.

What causes the vulnerability? 
The vulnerability results because of a flaw in how IE determines the correct security zone for handling scripts embedded in cookies and how that determination interacts with the zone classification for all cookies. Specifically, while scripting from different sites is, correctly, prohibited from accessing each other's content, IE treats attempts by script within cookies to access other cookies to be a legal and valid operation. This is because all cookies on the local file system are reckoned to be part of the same, single domain.
However, because cookies are not isolated content, but are tied to originating sites, this has the consequence of providing a means for a web site to illegally access and manipulate information contained within another site's cookie.

What are cookies? 
Cookies are small free-form data files that web sites use to store and retrieve information on a user's local system. That information can be useful during an individual browsing session a site and across multiple sessions with the same site. Cookies are often used for site customization for retaining user preferences, for example.
Be design, each site maintains and access its own cookies. By design, no other site should be able to access the cookies of another site.

What is IE's Cross-Domain Security Model? 
In a nutshell, the Cross-Domain Security model specifies that information from one website cannot access information from another web site.
This domain security model is used to enforce security on scripting. By design, scripts should be able to execute on content within the same domain. Using frames again as an example, this allows a click button in a table of contents frame to manipulate the display text from the same site in another frame. Additionally, by design, scripts should not be able to manipulate content from other domains.

How are cookies reckoned using IE's Cross-Domain Security Model? 
Under IE's Cross-Domain Security Model, cookies themselves are reckoned to all be part of the same domain. This is different from the reckoning of the sites which originate the cookies: each site is reckoned to be a seperate domain. However, all of the cookies of all websites are themselves reckoned to be part of the same domain on the local computer.
Suppose that you have Site A, www.sitea.com, and Site B, www.siteb.com. Each web site is correctly reckoned to be a seperate domain from the other. Suppose further that both sites have cookies stored on a user's local system. The cookies for these sites are actually reckoned to be part of the same domain. In other words, while Site A and Site B are in seperate domains, their cookies are reckoned together in the same domain, along with any other cookies on the local system.

Why can script be embedded in a cookie? 
Because cookies are free-form data files, there is no specific guideline or specification regarding how data should be stored, or what kind of data can be stored. Because of this, scripting is allowable content to be stored within a cookie. In essence, scripting is allowed in cookies because it has not been expressly prohibited in the specification for cookies.

Why can script in one cookie access another cookie? 
As noted above, the cross-domain model restricts a script's ability to interact with content from another domain. By design, however, a script can access the content of pages that are in the same domain. Since cookies are all reckoned in the same domain, any script that executes within a cookie can therefore access any other cookie because all other cookies are members of the same domain.

If this is a legal operation, why is this vulnerability? 
While the behavior is legal behavior for scripting in relation to other elements in the same domain, the net result of this behavior is in fact vulnerability. Because a web site controls its cookies on the local system, and because a sites cookies are able to read other cookies on the same system, ultimately it's possible that one site can read the cookies of another site. This behavior violates the integrity of cookies and is therefore a vulnerability.

Is this a Frame-Domain Verification vulnerability, like you patched in MS02-005? 
No. While the results of the vulnerability are nearly identical, the underlying flaw in this issue is quite different from that.

ou mentioned that IE Security zones play a role in this, how is that? 
As noted in MS02-015, cookies are governed by the IE security zone which governs their originating site. In nearly every case, this will be the Internet zone.
This means that the constraints and settings which govern web pages in the Internet zone also pertain to cookies on the local system. In this particular instance, this means that Active Scripting, which is enabled in the Internet zone by default, is thus enabled for cookies.

What could this vulnerability enable an attacker to do? 
At a high level, this vulnerability could allow an attacker to read or change the contents of another site's cookies.
In practical terms, what this means depends in large part on what is being stored in those cookies. Most sites that follow best practices don't store personal information within cookies. In that case, a successful attack carried out with this vulnerability would yield very little.
However, if a site did choose to store personal information, such as your favorite color, then an attacker could retrieve that information.

How could an attacker exploit this vulnerability? 
An attacker could seek to exploit this vulnerability by creating a specially formed cookie that contained script. He would then build a web page to control that cookie.
An attacker could attempt to levy this attack in one of two ways: He could post the web page on a server, or send it to the intended user as an HTML email.
It's important to note that the web page would have to know the specific name and location of any cookie it attempted to read. Without that information, the attack would fail.

What does the patch do? 
The patch eliminates the vulnerability by changing the zone which governs cookies to be the Restricted Site zone. Since Active Scripting is disabled by default in this zone, the net effect of this patch is to disable scripting in all cookies.

Zone Spoofing through Malformed Web Page (CVE-CAN-2002-0190):

What's the scope of the fourth vulnerability?
This is a privilege elevation vulnerability that relates to IE Security zones. Specifically, it could allow a web site to trick IE into believing that it was located on the user's intranet. In some very specific cases, it could be possible for a page to convince IE that it was a page in the Trusted Sites zone. In both cases, a successful attempt to exploit this would lead to the page being handled with fewer security restrictions that is appropriate.
To mount a successful attack using this vulnerability, an attacker would have to entice a user to visit a web site under his control. In addition, he would have to make the user visit the web site using NetBIOS rather than HTTP, which most likely would require him to have the user visit his site by first clicking a specially constructed hyperlink.

What causes the vulnerability? 
The vulnerability results because of a flaw in the determination of IE's Security Zones. Specifically, there is an error in relation to certain particularly malformed web pages when accessed using NetBIOS rather than HTTP. As a result, some pages can be determined to belong to the wrong IE Security Zone.

What are IE Security Zones? 
Security Zones are a feature in Internet Explorer that provides graded layers of security restrictions that govern what a actions a web site can take. As the zones increase in trustworthiness, the restrictions on sites within those zones decrease proportionately.
For example, the most strictly regulated zone is the Restricted Sites zone, which is for untrustworthy sites. Conversely, the Trusted Sites zone is the most permissive zone, and is appropriate for trustworthy sites.
In addition to these two zones, there is the Internet zone, which is the default zone for Internet sites not in the Trusted or Restricted sites zones as well as the Intranet zone, which is for web sites that are on the local network.
Because the local network is a controlled network, it is reckoned as more trustworthy than the Internet, which is an uncontrolled network. Because of this, the security restrictions on sites in the Intranet zone are somewhat less than those on site in the Internet zone.

What differences are there between the Internet zone and the Intranet zone?
The Internet and Intranet zones' default settings differ in only for areas, which are listed below:

• Java permissions. This setting defaults to "medium" in the Intranet Zone, but "high" in the Internet Zone
• Access data sources across domains. This is set to "prompt" in the Intranet Zone, but "disable" in the Internet zone.
• Don't prompt for certificate selection when no certificate or only one certificate exists. This is set to "enable" in the Intranet Zone, but "disable" in the Internet Zone.

What is NetBIOS? 
NetBIOS is a networking protocol that is primarily intended primarily for local network and provides support for higher-level networking functions such as file sharing. NetBIOS provides the core functionality for Windows-based networking.

What's wrong with the way IE's determines a web sites zone? 
There is a flaw in how IE determines a web site's zone, when that site is accessed using NetBIOS and the page is malformed in a particular manner. It erroneously determines that the web site is on the local Intranet, and is placed in the Intranet zone.
In addition, it is possible for the specially malformed page to convince IE that it is a page belonging to a site in the Trusted Sites zone. However this requires very specific information regarding the way the user has chosen to configure her system.

What could this vulnerability enable an attacker to do? 
An attacker could exploit this vulnerability to cause a web page to be rendered using the less restrictive security settings of the Intranet zone. The default settings would not allow any destructive action; however, many users customize the Intranet Zone and give intranet sites considerable latitude. Because of this, the actions that an attacker could take as a result of this vulnerability would depend on the specific customizations a user may have chosen to make to the Intranet zone. Again, however, in default conditions, these differences are few and the actions an attacker could take are not destructive.

How could an attacker exploit this vulnerability? 
An attacker could seek to exploit this vulnerability by creating a specially formed web page and posting it on a server. The attacker would then have to lure the user to their site.
However, it's important to note that the attacker would have to ensure that the user accessed the web page using NetBIOS rather than HTTP. In most cases, this means that the attacker would have to first make the user click on a special hyperlink that invokes the malformed page using NetBIOS.

Is there anything that mitigates against attempts to exploit this vulnerability? 
Yes. If a user were unable to reach the attacker's site using NetBIOS for any reason, the attempt to exploit the vulnerability would fail. For example, if an organization were blocking NetBIOS at the perimeter firewall, or an ISP were blocking NetBIOS across its routers, the page would be rendered using HTTP, then the attack would fail. Blocking NetBIOS is a well known best practices among companies and ISP's and should be considered a mitigating factor for this issue.

You said that in some particular cases a page would be reckoned to be a Trusted Site. How is that attack different from what's discussed above? 
For an attacker to attempt to elevate the zone setting of their page to the Trusted Sites, in addition to the steps already discussed, they would also have to have specific knowledge regarding how the intended victim has configured IE and used that information in the construction of the malformed web page. The vulnerability gives no means for an attacker to gather that information directly. In almost all cases then, the attacker would have to have first-hand knowledge of the user's system.

What does the patch do?
The patch eliminates the vulnerability by ensuring web sites' security zone is correctly determined.

Content Disposition Variants (CAN-2002-0193 and CAN-2002-0188):

What's the scope of the fifth and sixth vulnerabilities?
These vulnerabilities have essentially the same scope, even though they are two seperate flaws. In addition, they have essentially the same scope as the previous vulnerability. It can allow an attacker to run code of his choice on the user's system. That code could then take any action on the system which the user herself was capable of.

Where can I get more information on the "Content-Disposition" vulnerability? 
Microsoft Security Bulletin MS01-058 discusses this vulnerability in detail.

Is there anything different between these two variants and the original vulnerability? 
Yes. These two variants have a dependency which the original vulnerability did not have. Specifically, when the registered application for the associated file type that is being spoofed learns that the file is invalid, it must pass the file back to the operating system for handling rather than raising an error message itself. If the registered application halts the processing and raises an error message, then the flaw is not directly exploitable, and there is no vulnerability per se.
For example, suppose a site was offering an executable file that claimed to be a widget for download. Further suppose that widgets were considered by IE to be a safe file type, meaning that they would be passed directly to the registered application that handles widgets.
If the particular application that the user had on her system handled invalid widget files by raising an error message, there would be no opportunity for an attacker to exploit this vulnerability.
However, if that application instead handed the invalid file back to the operating system, then it would execuate, providing an attacker with a way to cause code of his choice to run.

Doesn't this mean then that the vulnerability lies in these registered applications? Why is this an IE vulnerability?
The underlying flaw that makes this a vulnerability lies in IE's initial handling of the invalid Content-Disposition header. It is this flaw that enables the attack vector. Therefore, this is the underlying vulnerability.

What does the patch do? 
The patch eliminates the vulnerability by ensuring that proper checking is instituted for spoofed Content-Disposition and Content-Type headers.

Restricted Sites Zone Enhancement to Disable Frames:

What's the scope of What's the scope of this enhancement?
This is an enhancement of the Restricted Sites zone in IE. Once the patch is applied, IE will block all frames within the Restricted Sites zone.
Because Outlook Express 6.0, Outlook 98 and Outlook 2000 with the Outlook Email Security Update, and Outlook 2002 all read mail in the Restricted Sites zone by default, this patch, by extension, now disables frames and IFRAMES in those products by default.
In addition, customers using Outlook Express 5.0, Outlook 98 and Outlook 2000 without the Outlook Email Security Update who choose to read mail in the Restricted Sites zone will also see frames and IFRAMES disabled in those products.
Finally, any web sites that users place in the "Restricted Sites" zone will no longer be able to use frame or IFRAMES.

Why are you making this enhancement? Does this mean that there was a vulnerability with frames and IFRAMES? 
No. There is no vulnerability or flaw in the behavior of frames and IFRAMES per se. The security mechanisms which govern them are robust and the features continue to be safe.
However, customers have indicated that they want the Restricted Sites zone to prohibit a site from being able to raise frames, especially in regards to the ability of HTML email to raise IFRAMES.
Based on that ongoing feedback, we made a behavior change that adds this new functionality to the Restricted Site zone.
We have chosen to make this enhancement to the Restricted Sites zone based on customer feedback and requests.

Download locations for this patch

• http://www.microsoft.com/windows/ie/downloads/critical/Q321232/default.asp