Microsoft Security Bulletin MS02-005

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.

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 causes the GetObject function 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.

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
• All patches available via WindowsUpdate also are available in a redistributable form from the WindowsUpdate Corporate site.