Microsoft Security Bulletin MS02-005 - Critical

Article
03/01/2023

11 February 2002 Cumulative Patch for Internet Explorer

Published: February 11, 2002 | Updated: May 09, 2003

Version: 1.1

Originally posted: February 11, 2002
Updated: May 09, 2003

Summary

Who should read this bulletin: Customers using Microsoft® Internet Explorer

Impact of vulnerability: Six vulnerabilities, the most serious of which could allow an attacker to run code on another user's system.

Maximum Severity Rating: Critical

Recommendation: Customers using an affected version of IE should install the patch immediately.

Affected Software:

Microsoft Internet Explorer 5.01
Microsoft Internet Explorer 5.5
Microsoft Internet Explorer 6.0

General Information

Technical details

Technical description:

This is a cumulative patch that, when installed, eliminates all previously discussed security vulnerabilities affecting IE 5.01, 5.5 and IE 6. In addition, it eliminates the following six newly discovered vulnerabilities:

A buffer overrun vulnerability associated with an HTML directive that's used to incorporate a document within a web page. By creating a web page that invokes the directive using specially selected attributes, an attacker could cause code to run on the user's system.
A vulnerability associated with the GetObject scripting function. Before providing a handle to an operating system object, GetObject performs a series of security checks to ensure that the caller has sufficient privileges to it. However, by requesting a handle to a file using a specially malformed representation, it would be possible to bypass some of these checks, thereby allowing a web page to complete an operation that should be prevented, namely, reading files on the computer of a visiting user's system.
A vulnerability related to the display of file names in the File Download dialogue box. When a file download from a web site is initiated, a dialogue provides the name of the file and lets the user choose what action to take. However, a flaw exists in the way HTML header fields (specifically, the Content-Disposition and Content-Type fields) are handled. This flaw could make it possible for an attacker to misrepresent the name of the file in the dialogue, in an attempt to trick a user into opening or saving an unsafe file.
A vulnerability that could allow a web page to open a file on the web site, using any application installed on a user's system. By design, IE should only open a file on a web site using the application that's registered to that type of file, and even then only if it's on a list of safe applications. However, through a flaw in the handling of the Content-Type HTML header field, an attacker could circumvent this restriction, and specify the application that should be invoked to process a particular file. IE would comply, even if the application was listed as unsafe.
A vulnerability that could enable a web page to run a script even if the user has disabled scripting. IE checks for the presence of scripts when initially rendering a page. However, the capability exists for objects on a page to respond to asynchronous events; by misusing this capability in a particular way, it could be possible for a web page to fire a script after the page has passed the initial security checks.
A newly discovered variant of the "Frame Domain Verification" vulnerability discussed in Microsoft Security Bulletin MS01-058. The vulnerability could enable a malicious web site operator to open two browser windows, one in the web site's domain and the other on the user's local file system, and to use the Document.open function to pass information from the latter to the former. This could enable the web site operator to read, but not change, any file on the user's local computer that could be opened in a browser window. In addition, this could be used to mis-represent the URL in the address bar in a window opened from their site.

Mitigating factors:

Buffer Overrun in HTML Directive:

The vulnerability could not be exploited if the "Run ActiveX Controls and Plugins" security option were disabled in the Security Zone in which the page was rendered. This is the default condition in the Restricted Sites Zone, and can be disabled manually in any other Zone.
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 email-borne attacks.
The buffer overrun would allow code to run in the security context of the user rather than the system. The specific privileges the attacker could gain through this vulnerability would therefore depend on the privileges accorded to the user.

File Reading via GetObject function:

This vulnerability could only be used to read files. It could not be used to create, change, delete, or execute them.
The attacker would need to know the name and location of the file on the user's computer.
Some files that would be of interest to an attacker - most notably, the SAM Database - are locked by the operating system and therefore could not be read even using this vulnerability.
The email-borne attack scenario would be blocked if the user were using any of the following: Outlook 98 or 2000 with the Outlook Email Security Update installed; Outlook 2002; or Outlook Express 6.
The web-based attack scenario could be blocked by judicious use of the IE Security Zones mechanism such as using the Restricted Sites zone.

File Download Dialogue Spoofing via Content-Type and Content-Disposition fields:

Exploiting this vulnerability would not give an attacker the ability to force code to run on a user's system. It would only enable the attacker to misrepresent the file name and type in the File Download dialogue. The download operation would not occur without the user's approval, and the user could cancel at any time.
The vulnerability could not be exploited if File Downloads have been disabled in the Security Zone in which the e-mail is rendered. This is not a default setting in any zone, however.
On versions of IE prior to 6.0, the default selection in the file download dialogue is to save, rather than open, the file. (In IE 6.0, the default is to open the file; however, this behavior is inappropriate, and the patch changes IE 6.0 to conform with the behavior of previous versions).

Application invocation via Content-Type field:

An attacker could only exploit this vulnerability if the application specified through the Content-Type field was actually installed on the user's system.
The vulnerability does not provide any way for the attacker to inventory the applications installed on the user's system and select one, nor does it provide any way to force the user to install a particular application.
The vulnerability would not provide any way to circumvent the security features of the application or to reconfigure it.
Outlook 2002 users who have configured Outlook to render HTML mail as plaintext would be at no risk from attack through HTML mail.

Script execution:

This vulnerability extends only to allowing scripts to run - it does not allow any other security restrictions to be bypassed. So, for instance, although an attacker could use this vulnerability to run a script, the script would still be subject to all other expected security settings.

Frame Domain Verification Variant via Document.Open function:

The vulnerability could only be used to view files. It could not be used to create, delete, modify or execute them.
The vulnerability would only allow an attacker to read files that can be opened in a browser window, such as image files, HTML files and text files. Other file types, such as binary files, executable files, Word documents, and so forth, could not be read.
The attacker would need to specify the exact name and location of the file in order to read it.

Severity Rating:

Buffer Overrun in HTML Directive:

	Internet Servers	Intranet Servers	Client Systems
Internet Explorer 5.01	None	None	None
Internet Explorer 5.5	Critical	Critical	Critical
Internet Explorer 6.0	Critical	Critical	Critical

File Reading via GetObject function:

	Internet Servers	Intranet Servers	Client Systems
Internet Explorer 5.01	Moderate	Moderate	Critical
Internet Explorer 5.5	Moderate	Moderate	Critical
Internet Explorer 6.0	Moderate	Moderate	Critical

File Download Dialogue Spoofing via Content-Type and Content-ID fields:

	Internet Servers	Intranet Servers	Client Systems
Internet Explorer 5.01	Moderate	Moderate	Moderate
Internet Explorer 5.5	Moderate	Moderate	Moderate
Internet Explorer 6.0	Moderate	Moderate	Moderate

Application Invocation via Content-Type field:

	Internet Servers	Intranet Servers	Client Systems
Internet Explorer 5.01	Moderate	Moderate	Moderate
Internet Explorer 5.5	Moderate	Moderate	Moderate
Internet Explorer 6.0	Moderate	Moderate	Moderate

Script Execution:

	Internet Servers	Intranet Servers	Client Systems
Internet Explorer 5.01	None	None	None
Internet Explorer 5.5	Moderate	Moderate	Moderate
Internet Explorer 6.0	Moderate	Moderate	Moderate

Frame Domain Verification Variant via Document.open function:

	Internet Servers	Intranet Servers	Client Systems
Internet Explorer 5.01	None	None	None
Internet Explorer 5.5	Moderate	Moderate	Critical
Internet Explorer 6.0	Moderate	Moderate	Critical

Aggregate severity of all vulnerabilities eliminated by patch:

	Internet Servers	Intranet Servers	Client Systems
Internet Explorer 5.01	Moderate	Moderate	Critical
Internet Explorer 5.5	Critical	Critical	Critical
Internet Explorer 6.0	Critical	Critical	Critical

The above assessment is based on the types of systems affected by the vulnerability, their typical deployment patterns, and the effect that exploiting the vulnerability would have on them.

Vulnerability identifier:

Buffer overrun: CAN-2002-0022
File reading via GetObject function: CAN-2002-0023
File download spoofing via Content-Type and Content-ID fields: CAN-2002-0024
Application Invocation via Content-Type field: CAN-2002-0025
Script execution: CAN-2002-0026
Frame Domain Verification Variant via Document.open function: CAN-2002-0027

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.

	IE 5.01 SP2	IE 5.5 SP1	IE 5.5 SP2	IE 6.0
Buffer overrun	No	Yes	Yes	Yes
File reading via GetObject function	Yes	Yes	Yes	Yes
File download spoofing via Content-Type and Content-ID fields	Yes	Yes	Yes	Yes
Application Invocation via Content-Type field	Yes	Yes	Yes	Yes
Script execution	No	Yes	Yes	Yes
Frame Domain Verification Variant via Document.open function	No	Yes	Yes	Yes

Frequently asked questions

What vulnerabilities are eliminated by this patch?
This is a cumulative patch that, when applied, eliminates all known security vulnerabilities affecting Internet Explorer 5.01, 5.5 and 6.0. In addition to eliminating all previously discussed vulnerabilities versions, it also eliminates six new ones: A vulnerability that could enable an attacker to take any action on another user's system that the user himself could take.

A vulnerability through which an attacker could read files from another user's system.
A vulnerability that could assist an attacker in convincing a user to download or run an unsafe file.
A vulnerability through which an attacker could start an application on another user's system.
A vulnerability that could enable a web page to flout one of the security settings a user had selected.
A newly discovered variant the "Frame Domain Verification" vulnerability discussed in Microsoft Security Bulletin MS01-058.

What's the scope of the first vulnerability?
This is a buffer overrun vulnerability. By creating a specially formed web page and either posting it on a web site or sending it to a user as an HTML mail, it could be possible for an attacker to take action on another user's system, including adding, creating or deleting files, communicating with web sites, or reformatting the hard drive. The vulnerability is subject to several mitigating factors:

The email-borne attack scenario would be blocked if the user were using any of the following: Outlook 98 or 2000 with the Outlook Email Security Update installed; Outlook 2002; or Outlook Express 6.
The web-based attack scenario could be blocked by judicious use of the IE Security Zones mechanism.
An attacker who successfully exploited this vulnerability could gain the same privileges as the legitimate user, but not system-level privileges. If the user had only few privileges on the system, the attacker would gain only those privileges; on the other hand, if the user had more privileges, the attacker would gain these as well.

What causes the vulnerability?
The vulnerability results because of an unchecked buffer in the implementation of an HTML directive that allows a web page to incorporate a document. By creating a web page that invokes this directive in the right way, an attacker could overrun the buffer and cause any desired code to run on the user's system.

What could this vulnerability enable an attacker to do?
An attacker could use this vulnerability to modify the functionality of IE while it was running. Because IE runs in the user's security context, this would enable the attacker to do anything on the user's system that the user himself could do. The specific actions the attacker could perform would depend on the privileges the user had on the system. If the user had few privileges, the attacker might be able to take relatively few actions; on the other hand, if the user had administrative privileges, the attacker could gain complete control over the system.

How could the attacker exploit the vulnerability?
The attacker would need to create a web page that, when opened, would invoke the HTML directive we discussed above, and cause the buffer overrun to occur. The attacker would likely use either of two strategies to cause another user to open the page:

Host the page on a web site. If a user visited the site and opened the web page, the page would attempt to exploit the vulnerability.
Send the page to a user as an HTML mail. If the recipient opened the mail, it would attempt to exploit the vulnerability.

In both of the scenarios, you said the web page would attempt to exploit the vulnerability. What's the significance of the word "attempt"?
A web page could only exploit the vulnerability if a particular security setting - "Run ActiveX Controls and Plugins" - has been enabled. If it's been disabled, the attacker couldn't exploit the vulnerability. This setting is enabled in some IE Security Zones, but disabled in others.

How great a risk does the web-borne scenario pose?
The principal advantage of the web-borne scenario to the attacker is that, by default, all Internet web sites reside in the Internet Zone, and the "Run ActiveX Controls and Plugins" setting is enabled there. This means that unless a user took special steps - either by disabling the setting in the Internet Zone or moving the attacker's web site into the Restricted Sites Zone - they'd be vulnerable. The disadvantage to the attacker is that the web-borne scenario would require enticing the user to the web site. This could require significant social engineering.

How great a risk does the mail-borne scenario pose?
The advantage to the attacker of the mail-borne scenario is that it could be used to attack a large number of users. The attacker could create a mail that exploits the vulnerability, and send it to as many users as desired. They would only need to open the mail to potentially be affected by it. The disadvantage to the attacker is that many users' systems are configured to open HTML mail in the Restricted Sites Zone, where the "Run ActiveX Controls and Plugins" setting is disabled by default. Specifically, the Outlook Email Security Update configures Outlook 98 or 2000 to open mail in the Restricted Sites Zone. Outlook 2002 and Outlook Express 6 open mail there by default.

I'm using one of the email products you listed above. Does this mean I don't need the patch?
The Outlook Email Security Update, Outlook 2002, and Outlook Express 6 will protect you against the mail-borne attack scenario. However, we still recommend that you install the patch, to ensure that you're protected against the web-based scenario.

How does the patch eliminate this vulnerability?
The patch restores proper buffer handling to the HTML directive at issue in this vulnerability.

What's the scope of the second vulnerability?
This vulnerability could allow an attacker to view files on the computer of another user. It could be exploited via either of two scenarios. An attacker could send a specially formatted HTML mail to another user which, when opened, would send a file's contents to the attacker; or the attacker could set up a web site that, when visited by a user, would read a file on the user's computer. There a number of significant mitigating factors associated with this vulnerability:

It could only be used to read files. It could not be used to create, change, delete, or execute them.
The attacker would need to know the name and location of the file on the user's computer.
The vulnerability could only be used to read files that aren't locked by the operating system. Some files that would be of interest to an attacker would therefore be unavailable even using this vulnerability.
The email-borne attack scenario would be blocked if the user were using any of the following: Outlook 98 or 2000 with the Outlook Email Security Update installed; Outlook 2002; or Outlook Express 6.
The web-based attack scenario could be blocked by judicious use of the IE Security Zones mechanism.

What causes the vulnerability?
The vulnerability results because the GetObject function's security checks can be spoofed if called using an argument that's been malformed in a particular way. This flaw could allow a web page to open and read files on a user's system.

What's the GetObject function?
GetObject is a scripting command that's used to establish contact with data files and other operating system objects. Before a script can work with such an object, it first has to use the GetObject function to access it.

What's wrong with the GetObject function?
When GetObject is invoked by a web page, it performs a series of security checks designed to ensure that the page can only use the object in ways that pose no threat to the user's data. However, by specifying the object in a particular way, it's possible to force GetObject to perform these checks incorrectly, and give the web page the ability to read files on the user's computer.

What would this vulnerability enable an attacker to do?
An attacker could use this vulnerability to read - but not create, delete or modify - files on another user's system.

How could the attacker exploit the vulnerability?
The attacker would need to create a web page that, when opened, invokes the GetObject function to open a file on the user's system. By specifying the file name as discussed above, the web page would exploit the vulnerability and gain the ability to read a file on the system of any user who opened the page. The attacker would likely deliver the page through one of two strategies:

Hosting the page on a web site. If a user visited the site and opened the web page, the page would attempt to exploit the vulnerability.
Sending the page to a user as an HTML mail. If the recipient opened the mail, it would attempt to exploit the vulnerability.

What files could the attacker read through the vulnerability?
The vulnerability can be used to read any file on the user's system, but the attacker would need to specify the exact location of the file. This would make it harder to exploit the vulnerability for several reasons:

It could be difficult for the attacker to guess the names and locations of files that other users have created. The vulnerability doesn't provide any way for the attacker to enumerate the files on the system and select one for reading.
Even though many system files are located in well-known places, these places vary from operating system to operating system. That is, a file that's located in one place in Windows 95 might be located in an entirely different place in Windows XP. The web page would have no way to tell which operating system a particular user was using.

I heard that an attacker could use this vulnerability to obtain my system's login password. Is this correct?
No. It's true that Windows NT®, Windows 2000, and Windows XP store an encrypted version of user passwords in a system data structure called the SAM Database, and that this database takes the form of a system file. It's also true that if an attacker obtained a copy of the SAM Database, it would be possible to subject it to a password cracking attack in which the attacker simply guesses passwords until the right one is found. However, this vulnerability does not provide a way for an attacker to read the SAM Database. The operating system locks this file (and other important system files) and doesn't allow any other processes to read it. So, even using this vulnerability, an attacker could not gain a copy of the SAM Database and crack a user's password.

How great a risk do the web-borne and mail-borne attack vectors pose?
The web-borne attack scenario would allow the attacker to attack targets of opportunity (i.e., users who happened to visit the web site). However, it wouldn't provide any way for the attacker to force specific users to visit the site. The mail-borne scenario would allow the attacker to attack selected users. However, it would require that the attacker know these users' email addresses. In addition, the mail-borne scenario would fail if the user had installed the Outlook Email Security Update on Outlook 98 or 2000; was using Outlook 2002 (which includes the Outlook Email Update by default); or was using Outlook Express 6.

How does the patch eliminate this vulnerability?
The patch causes the GetObject unction to correctly perform the expected security checks even in the case in which the file name is malformed as described above.

What's the scope of the third vulnerability?
The third vulnerability could enable an attacker to cause the wrong name to appear in a File Download dialogue box. An attacker could exploit this vulnerability in an attempt to fool a user into downloading an unsafe file. The vulnerability would not provide any way for the attacker to override normal system behavior with respect to the download. That is, it would not provide a way for the attacker to force the user to accept the download - the user could simply cancel the operation via the dialogue box.

What causes the vulnerability?
This vulnerability occurs because it's possible to manipulate the HTML header information in a web page in order to make the IE File Download dialogue display the wrong file name and type. By initiating a file download and using this vulnerability to misrepresent the name and type of file being downloaded, an attacker could create a situation in which the user might allow an executable or other unsafe file to run.

What are HTML headers?
HTML headers are fields within web pages that tell the browser how to handle certain aspects of the page. For instance, HTML headers may tell the browser how to render the page or interpret data on it. The vulnerability at issue here results because of a flaw in the way IE handles two HTML headers fields that tell it how to handle a non-HTML file referenced by a web page.

What do you mean by "a non-HTML file referenced by a web page"?
Web pages usually consist of HTML files - that is, files that contain commands that tell the browser what text to display and how to display it. However, in some cases, a web page may need to refer to a file that consists of other data. For instance, a web page might need to refer to a streaming media file, a text file, a program file, or some other type of data. Early browsers were built to read and display only HTML; all other files would be downloaded to the local system and the user would then open those files using the appropriate application. However, to provide a richer browsing experience, browser capabilities have been extended so that they can handle non-HTML files directly. For instance, IE handles .DOC files by opening them directly in WordPad or Word, and handles streaming media files by starting the user's media player and playing the file.

How does IE determine the appropriate way to handle a non-HTML file?
Most modern browsers, including IE, use Multipurpose Internet Mail Extensions (MIME) information to handle non-HTML data. MIME types were first developed so that Internet mail clients could handle file attachments intelligently, but their use has been extended so that browsers too can use them to handle files intelligently. When a web page instructs IE to download a non-HTML page, it provides the MIME type information via two HTML header fields, known as Content-Disposition and Content-Type. Once IE has determined the MIME type of the non-HTML file, it consults an internal table that tells it what the right way to handle the file is.

What are the Content-Disposition and Content-Type header fields?
The Content-Disposition and Content-Type header fields are used in conjunction to provide the MIME type information to the browser. The Content-Disposition field alerts the browser that non-HTML data is coming. The Content-Type field then provides the MIME type information.

What's wrong with the way IE handles the Content-Disposition and Content-Type header fields?
It's possible to insert information into these fields that will result in the wrong information being displayed when a download is initiated. For instance, an attacker could cause a file to be represented in the dialogue as "file.txt" when in fact it was actually named "file.exe".

What could this vulnerability enable an attacker to do?
It could potentially enable an attacker to create a web page that, when displayed, would start a file download and display a misleading name for the file, in the hope of convincing the user that it was safe to download. The page could be hosted on a web server or sent to a user as an HTML mail.

Where would the file be located?
The file would need to be located on a server that the attacker controlled. If that server couldn't be reached for some reason, the attack would fail.

Would the web page be able to automatically start such a download?
Yes. By design, a web page can always initiate a file download. However, it's important to be specific about what that means. The user is still in control of whether the download will proceed or not. That is, as soon as the file download starts, the File Download dialogue is displayed, and the user has the opportunity to cancel the download. Nothing in the vulnerability enables the attacker to prevent the user from simply choosing "Cancel" at the download dialogue.

If the user did choose to let the download proceed, what would happen?
It would depend on the user's choice:

Selecting "Open" would cause the program to run.
Selecting "Save" would cause the program to be saved to the user's system.
Selecting "Cancel" would cancel the download

What's the default selection in the File Download dialogue?
In all versions of IE prior to 6.0, the default selection in the File Download dialogue is to save the file. A bug in IE 6.0 makes the default selection there be to Open the file; however, this patch eliminates the bug and causes IE 6.0 to conform with previous versions' behavior.

If the user chose to save the file, would it be saved under its real name and type?
Yes. For instance, if the attacker had used this vulnerability to misrepresent file.exe as file.txt and the user chose the option to save the file rather than open it, the file would be saved as file.exe.

If the attacker can't force the user to accept the download, and can't force the program to run, why is this a security vulnerability?
In the web-borne scenario, this doesn't actually qualify as a security vulnerability. IE always lets the user identify the web site that he or she is visiting, and users should always base trust decisions like this on the degree to which they trust the site. That is, trust should be based on the source of the file, not what's displayed in a dialogue. However, the email-borne scenario is a different story, and is the reason why this qualifies as a security vulnerability. It's not possible to base trust on the source of an email. Not only is it simple to spoof an email address, many viruses cause infected systems to send copies of themselves to other users. That is, just because an email says it came from someone you trust, it doesn't mean that it actually did - and even if it did come from that person's email account, it doesn't necessarily mean that the person deliberately sent it.

One of the vulnerabilities discussed in Microsoft Security Bulletin MS01-058 also involved the Content-Disposition and Content-Type header fields. Is this the same issue?
No. Microsoft Security Bulletin MS01-058 did indeed discuss a vulnerability involving the handling of the same header fields, but the effect of that vulnerability was radically different than this one's. Where that vulnerability could be used to automatically run an executable, this one can only be used to misrepresent the file name.

How does the patch eliminate this vulnerability?
The patch causes IE to display the actual name of a downloaded file, regardless of the value of the Content-Disposition and Content-Type fields.

What's the scope of the fourth vulnerability?
This vulnerability could enable an attacker to use a web page to start one of the applications installed on a user's system, in conjunction with a file that the attacker supplied. In the worst case, this could enable the attacker to take serious action such as creating, modifying, or deleting data file, communicating with web sites, or reformatting the hard drive.
The actual actions that could be taken through this vulnerability would depend on which applications were installed on the user's system, the level of security each provided, and how they were configured. However, the attacker would have no way to determine which applications were installed, nor would the vulnerability provide any way to install additional ones or reconfigure the ones that were already installed.

What causes the vulnerability?
The vulnerability results because of a flaw in the way IE processes the Content-Type HTML header field. This flaw could allow a web page to specify that a particular application should be used to process a file downloaded from the web site, and that it's not necessary to request user permission before doing so.

Both this vulnerability and the previous one involve the Content-Type field. Are they related?
No. The only thing this vulnerability has in common with the previous one is the involvement of the Content-Type HTML header field. In all other respects, the vulnerabilities are completely unrelated.

What's wrong with how the Content-Type field is handled?
As we noted in the discussion above, the Content-Type field is used when downloading a file from a web site, and tells IE how to handle it. In particular, it provides information that lets IE determine what application should be used to open the file. By design, IE should only open files using their associated applications (e.g., Word documents should only be opened using Word). Moreover, they should only be opened automatically if the application is guaranteed to be incapable of taking any unsafe action. However, this vulnerability would enable a web page to bypass both of these restrictions - it could specify any desired application as the one that should be used to open the file, and IE would comply even if the application wasn't registered as a safe one.

What would this enable an attacker to do?
The vulnerability would enable an attacker to create a web page that would automatically download a file and open it using an application installed on the user's system. For instance, through this vulnerability it would be possible for an attacker to create a Word document containing an autoexecute macro (i.e., a macro that runs immediately upon the document being opened) and then open it. This could potentially allow the macro to run.

Why "potentially"? Wouldn't the macro run?
It would depend on how the user had configured Word. If it were configured to allow macros to run automatically, then the macro would run - and be capable of taking any action on the user's system. However, if Word were configured to disable macros (as it is by default), the macro wouldn't run.

How could an attacker exploit this vulnerability?
The web page containing the malformed Content-Type information could be hosted on the attacker's web site or sent to other users as HTML mail.

Where would the file be located?
The file would need to be located on a server that the attacker controlled. If that server couldn't be reached for some reason, the attack would fail.

What if the web page specified an application that wasn't installed on the user's system?
The attack would fail. The vulnerability doesn't provide any way for the attacker to determine what applications are on the user's system or to install new ones. The attacker would need to either know or guess which applications were installed.

Would the Outlook Email Security Update protect against the mail-borne attack scenario?
It wouldn't, because the setting that allows file downloads is enabled by default even in the Restricted Sites Zone. However, customers using Outlook 2002 could block the mail-borne scenario by configuring Outlook to render HTML mail as plaintext. Microsoft Knowledge Base article Q307594 provides information on this feature and how to use it.

How does the patch eliminate this vulnerability?
The patch restores the by-design operation of the Content-Type field that's discussed above in this section.

What's the scope of the fifth vulnerability?
This vulnerability could enable an attacker to build a web page that bypasses one of the security settings in Internet Explorer, and runs script even if the user has disabled it. The vulnerability affects only the single on/off setting for scripting - no other security settings could be bypassed through the vulnerability, and even if a script were run via this vulnerability, the IE security model would still restrict what it could do.

What causes the vulnerability?
The vulnerability results because of a flaw associated with an HTML directive that allows events to occur asynchronously on a web page. The directive could be misused to allow script to run even if scripting has been disabled by the user.

What do you mean by script?
Scripts are programs that enable web developers to manipulate the items on a web page. Many Web sites employ scripting to check the browser a user is running, validate input, work with controls, and communicate to the user. The user should always be in control of whether scripts are allowed to run or not. Specifically, the Security Zones mechanism lets you specify (via the security setting labeled "Active Scripting") whether scripts should run, and under what conditions. By default, scripting is enabled in all zones except the Restricted Sites Zone.

What do you mean when you say that the HTML directive at issue here "allows events to occur asynchronously on a web page"?
On many web pages, all of the text, graphics, and other items on the page are present when the page is rendered, and remain there for as long as the page is displayed. However, this doesn't have to be the case - it's also possible for items on a web page to join or leave the page in response to user actions or the passage of time. The vulnerability in this case revolves around an HTML directive that's used to do this.

What's wrong with the directive at issue here?
There isn't anything wrong with the directive per se - it works as advertised, and allows web items to "fire" in response to various events. The vulnerability results because IE performs its security checks when the page initially loads; by using this directive, script on a web could fire after the security checks have been completed, and run despite security settings to the contrary.

What could this vulnerability enable an attacker to do?
This vulnerability provides a way for a web page to bypass the user's security settings and run script even if scripting has been disabled. Such a web page could either be hosted on the attacker's web site, or sent to users as HTML mail.

Would the vulnerability provide a way to bypass any other security settings?
It wouldn't, and this is a critical point. The vulnerability only provides a way for a web page to initiate a script - it doesn't provide a way to bypass any other security constraints. The IE security model is designed to prevent scripts from taking unsafe actions, and this vulnerability doesn't change that. (There have, of course, been previously reported vulnerabilities involving the security model. But because this patch is cumulative, applying it will ensure that none of these remain).

How does the patch eliminate this vulnerability?
The patch ensures that scripts, regardless of when they are invoked, are only allowed to run if scripting has been enabled.

What's the scope of the sixth vulnerability?
This vulnerability is a new variant of the "Frame Domain Verification" vulnerability originally discussed in Microsoft Security Bulletin MS01-058. The vulnerability could allow a malicious web site operator to view files on the computer of visiting user. There a number of significant mitigating factors associated with this vulnerability:

It could only be used to read files - not create, change, delete, or execute them.
The attacker would need to know the name and location of the file on the user's computer
Even if successfully exploited, the attacker could only view files that can be opened in a browser window, such as HTML files, image files, or text files.
The vulnerability requires Active Scripting in order to succeed. If the malicious site were in a Security Zone that does not allow Active Scripting, the vulnerability could not be exploited.

Where can I get more information on the "Frame Domain Verification" vulnerability?
Microsoft Security Bulletins MS00-033, MS00-055, MS00-093, MS01-015 and MS01-058 discuss the vulnerability in detail.

Are there any differences between the new variant and the previous variants?
No. The scope of the new variant is exactly the same as for previous ones. The only difference lies in the specific function containing the flaw. In this case, the flaw lies in the Document.open function.

Does this patch eliminate the original variants as well as the new one?
Yes. It eliminates all known variants.

Patch availability

Additional information about this patch

Installation platforms:

The IE 5.01 patch can be applied to Windows 2000 Systems with Service Pack 2 running IE 5.01.
The IE 5.5 patch can be installed on systems running IE 5.5 Service Pack 1 or Service Pack 2.
The IE 6.0 patch can be installed on system running IE 6.0 Gold.

Inclusion in future service packs:

The fixes for these issues will be included in IE 6.0 Service Pack 1.
The fixes for the issues affecting IE 5.01 Service Pack 2 will be included in Windows 2000 Service Pack 3.

Reboot needed:

Yes

Superseded patches:

This patch supersedes the one provided in Microsoft Security Bulletin MS01-058, which is itself a cumulative patch.

Verifying patch installation:

To verify that the patch has been installed on the machine, open IE, select Help, then select About Internet Explorer and confirm that Q316059 is listed in the Update Versions field.
To verify the individual files, use the patch manifest provided in Knowledge Base article Q316059.

Caveats:

None

Localization:

Localized versions of this patch are available at the locations discussed in "Patch Availability"

Obtaining other security patches:

Patches for other security issues are available from the following locations:

Security patches are available from the Microsoft Download Center, and can be most easily found by doing a keyword search for "security_patch".
Patches for consumer platforms are available from the WindowsUpdate web site.

Other information:

Acknowledgments

Microsoft thanks the following people for working with us to protect customers:

The dH team and SECURITY.NNOV team for reporting the buffer overrun vulnerability.
Sandro Gauci of GFI security labs (https://www.gfi.com) for reporting the application invocation vulnerability.

Support:

Microsoft Knowledge Base articles Q316059, Q317727, Q317726, Q317745, Q317729, and Q317742 discuss these issues and will be available approximately 24 hours after the release of this bulletin. Knowledge Base articles can be found on the Microsoft Online Support web site.
Technical support is available from Microsoft Product Support Services. There is no charge for support calls associated with security patches.

Security Resources: The Microsoft TechNet Security Web Site provides additional information about security in Microsoft products.

Disclaimer:

The information provided in the Microsoft Knowledge Base is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.

Revisions:

V1.0 (February 11, 2002): Bulletin Created.
V1.1 (May 09, 2003): Updated download links to Windows Update.

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