What's the scope of the 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 be able to persuade the user to either browse to a web site she controlled or open an HTML e-mail that she had sent.
What causes the vulnerability?
If an HTML mail contains an executable attachment whose MIME type is incorrectly given as one of several unusual types, a flaw in IE will cause the attachment to be executed without displaying a warning dialogue.
Why is IE used to process HTML mails? I thought mail programs like Outlook and Outlook Express were in charge of displaying mails.
In general, they are. Mail clients handle creating, sending, receiving and displaying e-mail. There is one exception, however - they rely on IE to perform a process called "rendering" if the mail is an HTML mail. Rendering is the process of processing and displaying a web page. HTML mails are rendered by IE because they are essentially web pages sent as mails. The flaw in this case involves how IE renders HTML mails.
What's the problem with how IE renders HTML mails?
If a mail contains an attachment, IE should provide the ability to open the attachment when it renders the message. The precise meaning of "open" depends on the type of file. If the attachment is a text file, IE should provide the ability to read it; if it's a video clip, IE should provide the ability to view it; if it's a graphics file, IE should provide the ability to display it; and so on.
Some types of attachments, such as executable files, are inherently dangerous. In these cases, IE should only open the attachment if the user expressly asks to do so, and confirms that he wants to open it. The flaw, however, enables this safeguard to be circumvented by specifying an incorrect MIME type in the e-mail.
What's a MIME type?
Let's start with what MIME is. MIME is an acronym for Multipurpose Internet Mail Extensions. It's a widely used Internet standard for encoding binary files as e-mail attachments. When an e-mail contains a binary attachment, it must specify what type of file the attachment is, so the mail program can interpret it correctly.
In the case of this vulnerability, IE doesn't correctly handle certain types of fairly unusual MIME types. If an attacker created an e-mail message containing an executable attachment, and specified that it was one of these MIME types, IE would execute the attachment rather than prompting the user.
Would IE always execute the attachment?
No. IE would only execute the attachment if File Downloads were enabled in the Security Zone that the e-mail was opened in. However, File Downloads are enabled in all zones by default.
What would this vulnerability enable an attacker to do?
If an attacker created an e-mail that exploits this vulnerability, she could use it in an attempt to run the executable attachment on another user's computer. She could try to do this through either of two scenarios. First, she could host the HTML mail on her web site, and try to persuade the user to visit it. Second, she could send the email directly to the user.
What kind of actions could the attachment take if it ran?
The attachment would be able to take any action that the user himself could take on his system. If he were 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 an e-mail accidentally be created that would exploit this vulnerability?
No. To create such an e-mail, an attacker would need to create an e-mail containing an executable attachment, then deliberately edit the MIME headers in the mail to be one of the affected types.
What does the patch do?
The patch eliminates the vulnerability by correcting the table of MIME types and their associated actions in IE. This has the effect of preventing emails from being able to automatically launch executable attachments.
I've already installed IE 5.01 Service Pack 2. Do I need to install the patch?
No. The fix for this issue is included in IE 5.01 Service Pack 2. If you've already installed it, you do not need to install the patch.
Does this vulnerability affect IE 6?
No. You can eliminate the vulnerability by upgrading to IE 6. However, if you are running Windows 95, 98, 98SE or ME, you should be aware that you will need to install IE 6 in a certain way. Specifically, you will need to choose either the Full Install or Typical Install option. (The default installation type is Typical Install). If you choose Minimal Install or Custom Install, the files containing the vulnerability might not be upgraded, and your system could remain vulnerable.
Customers running Windows NT 4.0, Windows 2000, or Windows XP do not need to concern themselves with this contingency, as IE 6 does not provide either a Minimal or Custom Install option when installing on these systems. Any upgrade to IE 6 on one of these systems would fully eliminate the vulnerability. More information on this is available in Knowledge Base article Q308411.
I heard that even after applying this patch, an e-mail could start a file download automatically. Is this true?
Yes. However, this is not related to this vulnerability, and doesn't pose a security risk. It's always possible for an e-mail to start a file download, and of course the author of the mail can give the file a name that sounds innocuous. However, the file download cannot actually begin unless and until the user selects a location to which it should be downloaded, and clicks the OK button.
As a general rule, it is probably worth questioning the trustworthiness of any e-mail that automatically starts a file download. The best action is to simply click the Cancel button in the dialogue.
