Security Bulletin

Microsoft Security Bulletin MS01-058 - Critical

13 December 2001 Cumulative Patch for IE

Published: December 13, 2001 | Updated: May 09, 2003

Version: 1.3

Originally posted: December 13, 2001
Updated: May 09, 2003

Summary

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

Impact of vulnerability:
Run code of attacker's choice.

Maximum Severity Rating:
Critical

Recommendation:
Customers using IE should install the patch immediately.

Affected Software:

  • 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.5 and IE 6. In addition, it eliminates three newly discovered vulnerabilities.

  • The first vulnerability involves a flaw in the handling of the Content-Disposition and Content-Type header fields in an HTML stream. These fields, the hosting URL, and the hosted file data determine how a file is handled upon download in Internet Explorer. A security vulnerability exists because, if an attacker altered the HTML header information in a certain way, it could be possible to make IE believe that an executable file was actually a different type of file -- one that it is appropriate to simply open without asking the user for confirmation. This could enable the attacker to create a web page or HTML mail that, when opened, would automatically run an executable on the user's system. This vulnerability affects IE 6.0 only. It does not affect IE5.5 or 5.01.
  • The second vulnerability is a newly discovered variant of the "Frame Domain Verification" vulnerability discussed in Microsoft Security Bulletin MS01-015. 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 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. This vulnerabilty affects both IE 5.5 and 6.0.
  • The third vulnerability involves a flaw related to the display of file names in the File Download dialogue box. When a file download is initiated, a dialogue provides the name of the file. However, in some cases, it would be possible for an attacker to misrepresent the name of the file in the dialogue. This could be invoked from a web page or in an HTML email in an attempt to fool users into accepting unsafe file types from a trusted source. This vulnerabilty affects both IE 5.5 and 6.0.

Mitigating factors:

File Execution Vulnerability:

  • The vulnerability could not be exploited if File Downloads have been disabled in the Security Zone from which the file is being received. In most attempts to maliciously exploit this vulnerability the file would be received from the Internet or Intranet zone. Therefore, disabling File Downloads in these zones can protect customers. This is not the default setting for either of these zone, however.
  • This affects IE 6.0 only.

Frame Domain Verification Variant:

  • 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 file types, such as binary files, executable files, Word documents, and so forth, could not be read.
  • The attacker would have to have knowledge of the exact file name and location in other to successfully read the file on the local system.

File Name Spoofing Vulnerability:

  • The determination on choosing to accept a file download from an Internet site should always be based on the trustworthiness of the source and not on the file type. File downloads should never be accepted from an untrusted source, no matter how harmless the type may appear to be.

Severity Rating:

File Execution vulnerability:

Internet Servers Intranet Servers Client Systems
Internet Explorer 6.0 Critical Critical Critical

Frame Domain Verification Variant:

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

File Name Spoofing Vulnerability:

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

Aggregate severity of all vulnerabilities eliminated by patch:

Internet Servers Intranet Servers Client Systems
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. For the File Execution vulnerability, the vulnerability by-passes the security control for making trust decisions regarding file downloadings. For the Frame Domain Verification variant, the file would have to be of a type that could be displayed in a browser window and the full path and file name would have to be known to the attacker. For the File Name Spoofing vulnerability, file downloads from the Internet should be trusted on the basis of their source and not the file type. Finally, this aggregate rating includes ratings for issues addressed from previous patches which are superceded by this patch.

Vulnerability identifiers:

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
File Execution Vulnerability: No Yes Yes Yes
Frame Domain Verification Variant: No Yes Yes Yes
File Name Spoofing Vulnerability: Yes Yes Yes Yes

Frequently asked questions

What vulnerabilities are eliminated by this patch?
This patch, when installed, eliminates all known security vulnerabilities affecting Internet Explorer 5.5 and 6.0. In addition to eliminating all previously discussed vulnerabilities affecting these versions, it also eliminates three new ones:

  • A vulnerability involving the handling of downloads that can lead to automatic code execution.
  • A newly discovered variant of the the "Frame Domain Verification" vulnerability discussed in Microsoft Security Bulletin MS01-015.
  • A vulnerability involving the display of file names in the File Download dialogue box.

What's the scope of the first vulnerability?
This vulnerability could enable an attacker to potentially run a program of her choice on the machine of another user. Such a program would be capable of taking any action that the user himself could take on his machine, including adding, changing or deleting data, communicating with web sites, or reformatting the hard drive. In order for the attacker to successfully attack the user via this vulnerability, she would need to craft a specially formed web page and host the malicious executable on a site that is accessible to the victim, either on the Internet or on their local network. She would then have to force the user to view the web page. She could do this either by enticing the user to go to her site, or by sending the web page as an HTML email. When the web page on the site finished loading, the file could execute automatically. In the case of an HTML email, when the user opened the mail or viewed it in a preview pane, the file could execute automatically.

What causes the vulnerability?
The vulnerability results because it is possible to malform the HTML header information in a web page, in such a way as to misrepresent the filetype of a file that's referenced by the HTML page. If done properly, this could cause IE to handle the file inappropriately when opening the HTML page. In the worst case, a page could misrepresent an executable file as one that's safe to open without user confirmation, causing IE to automatically run an executable file when the HTML page was opened.

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.

So, is the problem that IE is handling certain MIME types incorrectly?
No. IE handles files appropriate for their MIME types - the problem in this case is that it's possible to convince IE that a file is of a different MIME type than it really is, by altering the Content-Disposition and Content-Header fields. IE would then handle the file in the wrong way, potentially with dangerous results.

What would this vulnerability enable an attacker to do?
An attacker could use this vulnerability to make a program run when a user opened a web page. Specifically, the attacker could create a program and host it on a web site, then create a web page that would open the program. By altering the Content-Disposition and Content-Header fields in a certain way, the attacker could tell IE that the program was actually a different type of file - one that's safe to simply open. The vulnerability could be exploited through either of two scenarios. The attacker could simply host the program and the web page on a web site, in order to attack anyone who visited the site. Alternatively, she could send the web page as an HTML mail; in this case, the program would be automatically executed when the recipient opened the mail.

Why would an attacker be able to exploit this via HTML email?
HTML mails are essentially web pages that are sent by mail. By creating a web page that exploits the vulnerability, and then sending it as an HTML mail, an attacker could mount essentially the same attack as discussed above via a web site. When the mail was opened, either by double-clicking the message or viewing it in a preview pane, the file would download and execute automatically.

Would the user have any opportunity to prevent the program from running?
He might. While the file was being downloaded, a dialogue would be displayed that would enable the user to cancel the download. If he cancelled the download before it was completed, the program could not run. However, how long the button would be available to halt the process would depend on the speed of the download and the size of the file.

What kind of actions could the executable take if it ran?
The executable would be able to take any action that the user himself could take on his system. The exact actions it could take would depend on the privileges of the user when they viewed the page and ran the attachment. If they were running in as an unprivileged user, it might be able to do very little. However, if the user were an administrator on his system, the attachment would be able to do virtually anything, including reformatting the hard drive.

Could a web page and executable accidentally be created that would exploit this vulnerability?
No. To create such a web page and executable, an attacker would need to craft the page and executable in a particular, purposeful way. This could not be done accidentally.

You said that the attacker would have to "post a malicious executable on a server", what does that mean?
For the attack to succeed, the malicious file would have to be downloaded to the user's computer. To accomplish this, the file would have to be placed in a location from which the user would be able to access it. If that server were unreachable for any reason, the attack would fail. This means, for example, that if a known server were hosting this malicious executable on the Internet, a company could protect its users by blocking access to that server. If a server on the local Intranet were hosting the executable, the threat would be eliminated if that server were removed from the network or made inaccessible through other means.

So, for the attack to succeed, the attacker needs to be able to download their file to my computer?
Correct. If the malicious executable cannot be downloaded for any reason, the attempted attack would fail. This offers an additional means of protecting against the attack. If File Downloads are disabled in the Security Zone from which the malicious code was being received, the attack would fail. Since most attempts to exploit this vulnerability would originate from the Internet, which is governed by the Internet Zone, or the local network, which is governed by the Intranet Zone, disabling file downloads in these zones would help to protect vulnerable systems. However, this setting is not the default for either zone.

What versions of IE are affected by this?
IE 6.0 only is affected by this. IE 5.5 is not affected by this particular vulnerability.

What does the patch do?
The patch eliminates the vulnerability by instituting proper checking for incorrect Content-Disposition and Content-Type headers.

What's the scope of the second vulnerability?
The second vulnerability is a new variant of the "Frame Domain Verification" vulnerability originally discussed in Microsoft Security Bulletin MS01-015. 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 file - 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, and MS01-015 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.

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

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. Likewise, even if the user did choose to allow the download to proceed, the attacker would have no way to make the file open - the default action is to save, not run, the file.

What causes the vulnerability?
This vulnerability occurs because, when the IE File Download dialogue encounters certain special characters, it stops displaying the file name. By carefully selecting a file name and inserting such a character into it at the proper place, an attacker could cause IE to display a misleading name for the file - one that the user might choose to trust.

What's wrong with the way the File Download dialogue handles file names?
When a web page initiates a file download, IE displays a dialogue that shows the file name and asks the user whether to save the file, open it, or cancel the download. By design, IE should display the entire name. However, a vulnerability exists because IE will actually stop displaying the name upon reaching certain special characters. This could enable an attacker to cause only a subset of the name to be displayed. For instance, suppose the attacker created a program named file.txt.exe. By inserting one of the special characters at issue here after the ".txt", the attacker could cause the file name to be shown in the dialogue as "file.txt", not "file.txt.exe".

What could this 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. The default choice in the File Download dialogue is to save the file to a location of the user's choosing on the system. If the user chose this option, the file would be stored on the system but would only run if the user later located the file and deliberately ran it. On the other hand, if the user chose the option to open it, the program would execute.

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 quality 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.

What does the patch do?
The patch causes IE's File Download dialogue to correctly handle special characters within file names.

Patch availability

Download locations for this patch

Additional information about this patch

Installation platforms:

  • The IE 5.5 patch can be installed on IE 5.5 Service Pack 2.
  • The IE 6 patch can be installed on IE 6 Gold.

Inclusion in future service packs:

The fix for these issue will be included in IE 5.5 Service Pack 3, and IE 6 Service Pack 1.

Reboot needed: Yes

Superseded patches: MS01-055.

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 Q313675 is listed in the Update Versions field.
  • To verify the individual files, use the patch manifest provided in Knowledge Base articles Q313675.

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 Jouko Pynnonen of Oy Online Solutions Ltd and Juan Carlos G. Cuartango of Instituto Seguridad Internet and Jesús López de Aguileta (aguileta@eunate.net) for reporting this issue to us and working with us to protect customers.

Support:

  • Microsoft Knowledge Base article Q313675 discusses this issue 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 (December 13, 2001): Bulletin Created.
  • V1.1 (February 08, 2002): Updated with table containing vulnerability information for IE 5.01 SP2 on Windows 2000, IE 5.5 SP1, IE 5.5SP2, and IE 6.0.
  • V1.2 (February 14, 2002): Updated Technical Details with vulnerability information for IE 5.01 SP2 on Windows 2000.
  • V1.3 (May 09, 2003): Updated download links to Windows Update.

Built at 2014-04-18T13:49:36Z-07:00