Microsoft Security Bulletin MS02-047

Technical description:

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

• A buffer overrun vulnerability affecting the Gopher protocol handler. This vulnerability was originally discussed in Microsoft Security Bulletin MS02-027, which provided workaround instructions while the patch provided here was being completed.
• A buffer overrun vulnerability affecting an ActiveX control used to display specially formatted text. The control contains a buffer overrun vulnerability that could enable an attacker to run code on a user's system in the context of the user.
• A vulnerability involving how Internet Explorer handles an HTML directive that displays XML data. By design, the directive should only allow XML data from the web site itself to be displayed. However, it does not correctly check for the case where a referenced XML data source is in fact redirected to a data source in a different domain. This flaw could enable an attacker's web page to open an XML-based files residing a remote system within a browser window that the site could read, thereby enabling the attacker to read contents from websites that users had access to but the attacker was not able to navigate to.
• A vulnerability involving how Internet Explorer represents the origin of a file in the File Download Dialogue box. This flaw could enable an attacker to misrepresent the source of a file offered for download in an attempt to fool users into accepting a file download from an untrusted source believing it to be coming from a trusted source.
• A Cross Domain verification vulnerability that occurs because of improper domain checking in conjunction with the Object tag. As a result, the vulnerability could enable a malicious web site operator to access data across different domains, for example one in a web site's domain and the other on the user's local file system and then 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 viewed n a browser window. In addition, this can also enable an attacker to invoke, but not pass parameters to, an executable on the local system, much like the "Local Executable Invocation via Object tag" vulnerability discussed in MS02-015.
• A newly reported variant of the "Cross-Site Scripting in Local HTML Resource" vulnerability originally discussed in Microsoft Security Bulletin MS02-023. Like the original vulnerability, this variant could enable an attacker to create a web page that, when opened, would run in the Local Computer zone, allowing it to run with fewer restrictions than it would in the Internet Zone.

In addition, the patch sets the Kill Bit on the MSN Chat ActiveX control discussed in Microsoft Security Bulletin MS02-022 as well as the TSAC ActiveX control discussed in Microsoft Security Bulletin MS02-046. This has been done to ensure that vulnerable controls cannot be introduced onto users' systems. Customers who use the MSN Chat control should ensure that they have applied the updated version of the control discussed in MS02-022 and customers who use the TSAC control should ensure that they have applied the updated version of the control discussed in MS02-046 .

Mitigating factors:

Buffer Overrun in Gopher Protocol Handler:

• The vulnerability would provide the attacker with user's own privileges on the system. Customers who run with fewer than full privileges on the system would therefore be at lower risk.

Buffer Overrun in Legacy Text Formatting ActiveX Control:

• The vulnerable ActiveX control is not installed by default as part of a current version of IE. Upon learning of the vulnerability, Microsoft removed the download from its site to minimize the likelihood that users would have the control on their systems.
• The vulnerability would provide the attacker with the user's own privileges on the system. Customers who run with fewer than full privileges on the system would therefore be at lower risk.
• Customers who use Outlook Express 6.0 or Outlook 2002 (or Outlook 98 or 2000 in conjunction with the Outlook Email Security Update) would by default by protected against email-borne attacks via this vulnerability unless they specifically clicked a link within the email message.

XML File Reading via Redirect:

• The vulnerability only provides a capability to read XML-based files that they know the complete path to.
• The vulnerability could not be used to add, change or delete files.
• Customers who use Outlook Express 6.0 or Outlook 2002 (or Outlook 98 or 2000 in conjunction with the Outlook Email Security Update) would by default by protected against email-borne attacks via this vulnerability.

File Origin spoofing:

• The vulnerability does not give an attacker the means to place or run executables directly on the system: user interaction is required in a successful attack.

Cross Domain Verification in Object Tag:

• The vulnerability would not enable the attacker to pass any parameters to an executable program. Microsoft is not aware of any programs installed by default in any version of Windows that, when called with no parameters, could be used to compromise the system.
• An attacker could only invoke a file on the victim's local machine. The vulnerability could not be used to execute a program on a remote share or web site.
• The vulnerability would not provide any way for an attacker to put a program of his choice onto another user's system.
• An attacker would need to know the name and location of any file on the system to successfully invoke it.
• The vulnerability could only be used to view or invoke files. It could not be used to create, delete, or modify them.
• The vulnerability would only allow an attacker to read files that can be rendered 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.
• 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.

Variant of Cross-Site Scripting in Local HTML Resource:

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

Severity Rating:

Buffer Overrun in Gopher Protocol Handler:

Buffer Overrun in Legacy Text Formatting ActiveX Control:

XML File Reading via Redirect:

File Origin Spoofing:

Cross Domain Verification in Object Tag:

Variant of Cross-Site Scripting in Local HTML Resource:

Aggregate Severity of all issues included in this patch (including issues addressed in previously released patches):

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 identifiers:

• Buffer Overrun in Gopher Protocol Handler: CAN-2002-0646
• Buffer Overrun in Legacy Text Formatting ActiveX Control: CAN-2002-0647
• XML File Reading via Redirect: CAN-2002-0648
• File Origin Spoofing: CAN-2002-0722
• Cross Domain Verification in Object Tag: CAN-2002-0723
• Variant of Cross-Site Scripting in Local HTML Resource: CAN-2002-0691

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 on Windows® 2000.

What vulnerabilities are eliminated by this patch?
This is a cumulative patch that incorporates the functionality of all previously released patches for Internet Explorer. In addition, the patch eliminates six newly reported vulnerabilities:

• A vulnerability originally discussed in Microsoft Security Bulletin MS02-027, that could enable an attacker to take any action on another system that the system's legitimate user could take.
• A vulnerability that could enable an attacker to run code on a user's system in the context of the user
• A vulnerability that could, under certain conditions, enable an attacker to read certain types of data files on another user's system
• A vulnerability that could enable an attacker to misrepresent the origin of a file offered for download.
• A vulnerability that could enable a malicious web site operator to read, but not change, any file on the user's local computer that could be viewed n a browser window. In addition, the vulnerability enable an attacker to invoke, but not pass parameters to, an executable on the local system.
• A new variant of a vulnerability originally discussed in Microsoft Security Bulletin MS02-023, that could allow an attacker to cause script to be run in the Local Computer Zone.

Does the patch include any other changes?
Yes. The patch ensures that a component that was the subject of Microsoft Security Bulletin MS02-022 cannot be used as well as ensuring that the TSAC control that was the subject of Microsoft Security Bulletin MS02-046 cannot be used. This has been done to prevent these component from being reintroduced onto users' systems. The components at issue here is associated with MSN Chat, TSAC; customers who use MSN Chat and have not already installed the patch provided in MS02-022 should do so before installing this patch and customers who use TSAC and have not already installed the patch provided in MS02-046 should do so before installing this patch.

Buffer Overrun in Gopher Protocol Handler (CAN-2002-0646):

What's the scope of first vulnerability?
This vulnerability was originally announced via Microsoft Security Bulletin MS02-027. As discussed in the bulletin, the vulnerability could enable an attacker to take any action on a user's system that the user himself could take. Examples of actions the attacker could take include loading and running programs, sending data from the user's system to a web site, reformatting the hard drive, and so forth. It could be possible to exploit the vulnerability through either of two vectors: by hosting a specially constructed web page on a web site, or by sending such a web page to another user as an HTML mail.
When the vulnerability was originally announced, Microsoft offered a workaround that customers could use to protect their systems. A complete fix is now available, and is included in this patch.

Is the description of the vulnerability provided in Microsoft Security Bulletin MS02-027 still accurate?
Yes. The information in Microsoft Security Bulletin MS02-027 still represents a complete description of the vulnerability and the risk it poses.

How does the patch eliminate the vulnerability?
The patch eliminates the vulnerability by instituting proper buffer handling within the Gopher protocol handler. It also disables the use of the Gopher protocol by default.

Why does the patch disable Gopher?
Very few customers use Gopher today. Customers who do use Gopher can easily enable it, but for the majority of users the most appropriate default condition is to have the protocol disabled.

I do use Gopher. How do I re-enable support after installing the patch?
First, if you followed the workaround instructions in Microsoft Security Bulletin MS02-027, you'll need to undo those changes. Microsoft Knowledge Base article Q326185 provides instructions for doing this.
Next, you'll need to set the following registry key to enable Gopher via the patch:

After installing the patch, should I undo the workaround that was discussed in MS02-027?
It's not necessary to reverse the workaround, but you can if you want to. Microsoft Knowledge Base article Q326185 provides instructions for doing this.

Buffer Overrun in Legacy Text Formatting ActiveX Control (CAN-2002-0647):

What's the scope of second vulnerability?
This is a buffer overrun vulnerability. An attacker who successfully exploited it would gain the ability to take any action on a user's system that the user himself could take. This could enable the attacker to run programs, communicate with web sites, reformat the hard drive, or take other actions. The attacker could attempt to exploit the vulnerability through either of two vectors: by hosting a specially constructed web page on a web site, or by sending such a web page to another user as an HTML mail.
The vulnerability is subject to several constraints:

• The vulnerable ActiveX control is not installed by default as part of Internet Explorer, but is instead automatically downloaded from a Microsoft web site when first used. Microsoft has removed the control from its site to prevent future downloads.
• Outlook Express 6.0, Outlook 98 and Outlook 2000 with the Outlook Email Security Update, and Outlook 2002 all read mail in the Restricted Sites zone by default. ActiveX controls are disabled by default in that zone, and as a result customers using these products would not be at risk from HTML email attack.

What causes the vulnerability?
The vulnerability results because an obsolete ActiveX control used for certain types of text formatting contains an unchecked buffer. If called by a web site in a particular way, the buffer could be overrun, with the result that an attacker could cause the control to take action on the user's system.

What are ActiveX controls?
Let's start by discussing the ActiveX technology. ActiveX allows developers to write small, self-contained software modules, each of which performs a single task or a small number of related tasks. The advantage of doing this is that other programs can call the modules, thereby avoiding the need for these programs to implement the software themselves.
The modules we've been referring to are more properly known as ActiveX controls. Internet Explorer is one of the many programs that makes use of them. ActiveX controls are available that implement a wide variety of functions that are useful for web browsing. In this case, the vulnerability lies within one such ActiveX control.

What's the ActiveX control that contains the vulnerability?
The vulnerability lies within an ActiveX control that enables web pages to display text in a variety of formats. With the advent of DHTML, a technology that enables web sites to be automated and animated easily, the control was no longer needed. However, it was retained for backward compatibility.

Did the control ship as part of Internet Explorer?
No. The control was hosted on a Microsoft site, from which point it would be automatically downloaded the first time needed.

What's wrong with the control?
The control contains an unchecked buffer. If called using a particular type of malformed input value, the buffer could be overrun. The effect would be, in essence, to change the functionality of the control and make it take new actions instead of those it's programmed to take.

What would this vulnerability enable an attacker to do?
An attacker could use this vulnerability to take action on another user's computer. Depending on exactly how the attacker overran the buffer, he or she could cause the control to take any desired action that the legitimate user could take. This could include actions such as downloading programs from remote sites and running them, sending data from the user's system to a web site, or simply reformatting the hard drive.
On the other hand, if the user did not have privileges to perform to particular action, neither would the attacker. Because of this, customers who operate with less than Administrator privileges on their systems would be at less risk.

How might an attacker exploit the vulnerability?
The attacker would need to construct a web page that calls the control and provides the malformed input value discussed above. The attack could then proceed via either of two vectors. In the first, the attacker could host the web page on a web site; when a user visited the site, the web page would attempt to run the control and exploit the vulnerability. In the second, the attacker could send the web page as an HTML mail. Upon being opened by the recipient, the web page could attempt to run the control and exploit the vulnerability.

You said the web page could "attempt" to run the control. What would determine whether this attempt was successful?
Two factors would determine whether the attack was successful:

• Whether the control was present on the user's system. If the control wasn't present on the system, it couldn't be called. As discussed above, Internet Explorer typically would attempt to automatically download the control when a web page requested it. However, upon learning of this vulnerability, Microsoft removed the control from its download site in order to minimize the number of users who have the control on their systems.
• Whether ActiveX controls were allowed to run on the user's system. The Internet Explorer Security Zones mechanism provides a way of regulating what actions various web sites can take - among them, whether they can run ActiveX controls. By default, web pages in the Restricted Sites Zone cannot run ActiveX controls. This turns out to be especially significant in the case of an attack via the HTML mail vector.

Why is that?
By default, Outlook Express 6.0 and Outlook 2002 open HTML mails in the Restricted Sites Zone. In addition, Outlook 98 and 2000 open HTML mails in the Restricted Sites Zone if the Outlook Email Security Update has been installed. Customers who use any of these products would be at no risk from the email attack vector.

How does the patch eliminate the vulnerability?
The patch eliminates the vulnerability by setting the "kill bit" on the affected ActiveX control. This action, which is discussed in more detail in Microsoft Knowledge Base Article Q240797, has the effect of preventing a particular ActiveX control from ever being executed within Internet Explorer, regardless of the security settings on the system.

XML File Reading via Redirect (CAN-2002-0648):

What's the scope of third vulnerability?
This vulnerability could enable an attacker to read the entire contents of certain types of files, and fragments of other types, from another user's system. The vulnerability could be exploited through either of two vectors: by hosting a specially constructed web page on a web site, or by sending a web page as an HTML mail. The vulnerability is subject to several restrictions:

• The attacker would need to know (or guess) the exact path and file name of the file.
• Only certain types of files could be read through the vulnerability - specifically, XML based files.
• The vulnerability could only be used to read files. It could not be used to add, change or delete them.
• By default, Outlook Express 6 and Outlook 2002, as well as Outlook 98 and 2000 if the Outlook Email Security Update has been installed, would not be vulnerable to the email-borne vector.

What causes the vulnerability?
The vulnerability results because of a flaw in the way Internet Explorer handles certain requests to display XML content. By design, Internet Explorer should only display the data if it resides on the web site; however, in reality the data source can be redirected to a file on a remote system, with the result that the web site could read XML content (and in some cases, fragments of other file types) belonging to the remote system.

What is XML?
Extensible Markup Language, or XML, is a data format that provides a way for disparate applications to share data. Data for a wide variety of purposes can be stored as XML data and used by other programs. Internet Explorer provides features that allow it to display and use XML data. However, one of those features contains a security vulnerability.

What's wrong with the way Internet Explorer handles XML data?
Among the features Internet Explorer provides for handling XML data is one that lets it open an XML data file on a web site and display the content in a browser window. However, the flaw makes it possible for the web site to instead open an XML file on a remote system in the browser window. Specifically, the feature at issue here checks to make sure that the web page requests a data source that resides on the same web site, but doesn't check to make sure that the data source isn't redirected.

What do you mean by "redirected"?
On many web sites, new web pages come and go frequently as new content is developed and delivered. When a user requests a page that no longer exists, one way to handle the situation is to simply send a "page not found" error. However, it's often preferable to seamlessly send the user to the content that replaces what they requested.
Redirects provide a way to do this. For instance, a web site operator can set up a redirect so that when a user requests web page A, they actually are served web page B. In the case of this vulnerability, the problem results because the XML data source that's specified in the web page may have actually been redirected to a file on the user's computer. Internet Explorer's inability to properly handle the situation results in a violation of the Internet Explorer cross-domain security model.

What's the Internet Explorer cross-domain security model?
One of the principal security functions of a browser is to ensure that web sites can only see data that belongs to them. To enforce this restriction, Internet Explorer implements the concept of "domains". Simply put, a domain is a security boundary. A web site can read data from any browser window that lies within the site's domain - that is, that's open to a page on the site. However, it should not be able to read data from any other domain.
In this case, the window that is open to the web site lies within the site's domain, so the site can read any data that's in it. But the flaw allows XML data from the remote system website rather than the initial web site, to be read. The fact that the web site can read data from a different domain (namely, the remote website) violates cross-domain security.

What could this vulnerability enable an attacker to do?
This vulnerability could enable an attacker to read XML data file on other remote systems. In addition, the attacker could read fragments of non-XML files - although this capability would be very limited websites that users were not able to navigate to.

How could an attacker exploit this vulnerability?
The attacker would need to construct a web page that opens an XML file that purportedly resides on the server, then redirect the putative XML file to a location on the remote system. The attack could then proceed via either of two vectors. In the first, the attacker could host the web page on a web site. In the second, the attacker could only send a link to the web page in mail In either case, when the web page opened, Internet Explorer would open the file on the user's system, within a browser window that would lie within the web site's domain. The page could then read the data and send it to the web site.

How would the attacker know where an XML file resided on the remote system?
In most cases, the attacker wouldn't know this information. He or she would need to either know or guess significant information about the location of the XML file on the user's system.

Could the attacker change the data on the user's system?
No. The vulnerability would only enable the attacker to read data - not change, add, or delete it.

Would certain email clients be at less risk than others from the mail-borne attack vector?
Yes. As in the case above, customers using Outlook Express 6.0 or Outlook 2002, or those using Outlook 98 or 2000 in conjunction with the Outlook Email Security Update, would be at much less risk. In all of these cases, HTML mail is opened by default in the Restricted Sites Zone, and this would prevent the vulnerability from being exploited.

How does the patch eliminate the vulnerability?
The patch changes the feature that contains the vulnerability, and causes it to refuse to open any XML data that has been redirected outside of the web site.

File Origin Spoofing (CAN-2002-0722):

What's the scope of fourth vulnerability?
This vulnerability can cause the wrong origin to appear in a File Download dialogue box. An attacker could exploit this vulnerability in an attempt to fool a user into downloading a file from an untrusted source, believing it originates at a trusted source.
The vulnerability does not provide a means for the attacker to change the behavior of the file downloads. Specifically, the user would still have to accept the download. However, because the trustworthiness of files offered for download should be based on the source of the file, this vulnerability can enable an attacker to undermine the soundness of that trust decision by providing the user with false information.

What causes the vulnerability?
This vulnerability occurs because of an error in how the URL of the originating server is determined by IE when processing a specially formed URL link. Specifically, if the IE File Download dialogue encounters certain special characters, it stops displaying the proper download location. By carefully crafting a URL that points to a file for download an attacker could cause IE to display a misleading origin for the file - one that the user might choose to trust.

What's wrong with the way the File Download dialogue handles file origins?
When a URL link initiates a download, IE performs processing to present the name and origin of the file for download. These are then presented to the user when IE displays a dialogue that asks the user whether to save the file, open the file, or cancel the download. The user can then evaluate the trustworthiness of the file based on the location as presented, and take appropriate action.
There is a flaw in how IE determines the origin name to be displayed, when the URL for the download is specially malformed. Specifically, it is possible to cause a false origin to be displayed in the file download dialogue box. For example, an attacker could host a file on www.untrustedsite.com but it would be shown in the file download dialogue box as originating from www.trustedsite.com.

What could this enable an attacker to do?
This could enable an attacker to trick a user into making an invalid trust decision regarding a file offered for download on the Internet. Since the trustworthiness of a file should be based on the source of a file, this vulnerability provides a means by which an attacker can trick a user into making an invalid trust decision by presenting false information for that decision. As a consequence of this, the user could be tricked into accepting a file from what the user believes is a trusted source when, in fact, it actually originates from an untrusted source.

How might an attacker seek to exploit this vulnerability?
An attacker could seek to exploit this vulnerability by crafting a web page with the specially crafted URL. The attacker could then either post it on a web site or send it as an HTML email to the user.

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.

What does the patch do?
The patch addresses the vulnerability by ensuring that IE correctly determines the origin of a file download and displays is properly.

Cross Domain Verification in Object Tag (CAN-2002-0723):

What's the scope of fifth vulnerability?
This is a vulnerability that can allow one web site to access information in another domain, including the local system. As a result, it's possible for a web site to read files on the local file system that can be rendered in a browser, or to invoke executables on the local file system.

The ability to read information on the local file system sounds similar to the "Frame Domain Verification" vulnerability discussed in MS02-005, is this a variant of that?
No. The flaw that causes this vulnerability is different than the flaw which causes the "Frame Domain Verification" vulnerability. However, the scope of these two vulnerabilities are, in essence, identical. In both cases the vulnerability can be used to read files on the local system that can be rendered in a browser, provided the attacker knows the full path and file name.

The ability to invoke executables sounds similar to the scope of the "Local Executable Invocation via Object tag" vulnerability in MS02-015. Is this a variant of that vulnerability?
No. The flaw that causes this vulnerability is different from the flaw which causes the "Local Executable Invocation via Object tag" vulnerability. However, these two vulnerabilities both have the same scope: an attacker could use this vulnerability to invoke an application already present on the system.

Are the mitigating factors for the "Frame Domain Verification" vulnerability applicable to this vulnerability?
Yes. The same mitigating factors that constrain the "Frame Domain Verification" vulnerability apply to this vulnerability

Are the mitigating factors for the "Local Executable Invocation via Object tag" vulnerability applicable to this vulnerability?
Yes. The same mitigating factors that constrain the "Local Executable Invocation via Object tag" vulnerability apply to this vulnerability.

What causes the vulnerability?
The vulnerability results because of improper domain verification when the Object tag is used in a particular manner.

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.

Where can I get more information on the Local Executable Invocation via Object tag?
Microsoft Security Bulletin MS02-015discusses the vulnerability in detail.

Are all versions of Internet Explorer equally affected by the vulnerability?
Internet Explorer 5.5, and 6 are all affected by the vulnerability. Internet Explorer 5.01 is not affected by this vulnerability.

How does the patch address the vulnerability?
The patch institutes proper domain checking when the Object tag is invoked.

Variant of Cross-Site Scripting in Local HTML Resource (CAN-2002-0691):

What's the scope of sixth vulnerability?
This is a new variant of a vulnerability originally discussed in Microsoft Security Bulletin MS02-023. As in the original variant, an attacker who was able to successfully exploit this vulnerability could cause HTML scripts to execute as if they were run locally on the user's system. As a consequence, the scripts could take any action on the local system as if it were run locally.

Are there any differences between this new variant and the original one discussed in MS02-023?
No. The scope, effect, and general method of exploitation all are the same as for the original variant.

Are all versions of Internet Explorer equally affected by the vulnerability?
Internet Explorer 5.01, 5.5, and 6 are all affected by the vulnerability. However, the patch that was delivered in Microsoft Security Bulletin MS02-023 eliminated both the original and new variants for Internet Explorer 6.

Does the patch eliminate the original as well as the new variant?
Yes.

Download locations for this patch

• http://www.microsoft.com/windows/ie/ie6/downloads/critical/q323759ie/default.mspx