Microsoft Security Bulletin MS03-004
Cumulative Patch for Internet Explorer (810847)
Originally posted: February 5, 2003
Updated: February 19, 2003
Who should read this bulletin:
Customers using Microsoft® Internet Explorer.
Impact of vulnerability:
Allow an attacker to execute commands on a user's system.
Maximum Severity Rating:
Customers should install the patch immediately.
- Microsoft Internet Explorer 5.01
- Microsoft Internet Explorer 5.5
- Microsoft Internet Explorer 6.0
End User Bulletin:
An end user version of this bulletin is available at: http://www.microsoft.com/athome/security/update/bulletins/default.mspx
Subsequent to the initial release of this bulletin, a non-security issue was discovered with the IE 6 version of this patch that could affect some users - primarily consumers - under certain conditions. Specifically, the issue could cause some IE 6 users to be unable to authenticate to certain Internet web sites such as subscription based sites, or MSN e-mail. This issue has been resolved, and a hot fix (813951) issued to correct it. It is important to note that this hot fix corrects a very specific non-security issue in IE 6 only, and that the security patch discussed in this Security Bulletin was, and still is, effective in removing the vulnerabilities discussed later in this bulletin. More information, including details of how to obtain the hot fix are available at: http://www.microsoft.com/windows/ie/ie6/downloads/critical/813951/default.mspx and in the Frequently Asked Questions section of this bulletin.
This is a cumulative patch that includes the functionality of all previously released patches for IE 5.01, 5.5, 6.0. In addition, it eliminates two newly discovered vulnerabilities involving Internet Explorer's cross-domain security model - which keeps windows of different domains from sharing information. These flaws results in Internet Explorer because incomplete security checking causes Internet Explorer to allow one website to potentially access information from another domain when using certain dialog boxes.
In order to exploit this flaw, an attacker would have to host a malicious web site that contained a web page designed to exploit this particular vulnerability and then persuade a user to visit that site. Once the user has visited the malicious web site, it would be possible for the attacker to run malicious script by misusing a dialog box and cause that script to access information in a different domain. In the worst case, this could enable the web site operator to load malicious code onto a user's system. In addition, this flaw could also enable an attacker to invoke an executable that was already present on the local system.
A related cross-domain vulnerability allows Internet Explorer's showHelp() functionality to execute without proper security checking. showHelp() is one of the help methods used to display an HTML page containing help content. showHelp() allows more types of pluggable protocols than necessary, and this could potentially allow an attacker to access user information, invoke executables already present on a user's local system or load malicious code onto a user's local system.
The requirements to exploit this vulnerability are the same as for the issue described above: an attacker would have to host and lure a user to a malicious web site. In this scenario, the attacker could open a showHelp window to a known local file on the visiting user's local system and gain access to information from that file by sending a specially crafted URL to a second showHelp window. The attacker could also potentially access user information or run code of attacker's choice.
This cumulative patch will cause window.showHelp( ) to cease to function. When the latest HTML Help update - which is being released via Windows Update with this patch - is installed, window.showHelp( ) will function again, but with some limitations (see the caveats section later in this bulletin). This has been necessary in order to block the attack vector that might allow a web site operator to invoke an executable that was already present on a user's local system.
- The attacker would have to host a web site that contained a web page used to exploit either of these cross-domain vulnerabilities.
- The attacker would have no way to force users to visit the site. Instead, the attacker would need to lure them there, typically by getting them to click on a link that would take them to the attacker's site.
- By default, Outlook Express 6.0 and Outlook 2002 open HTML mail in the Restricted Sites Zone. In addition, Outlook 98 and 2000 open HTML mail 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 an e-mail borne attack that attempted to exploit this vulnerability unless the user clicked a malicious link in the email.
- Internet Explorer 5.01 users are not affected by the first vulnerability.
|Internet Explorer 5.01||Critical|
|Internet Explorer 5.5||Critical|
|Internet Explorer 6.0||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.
- Improper Cross Domain Security Validation with dialog box CAN-2003-1326
- Improper Cross Domain Security Validation with ShowHelp functionality CAN-2003-1328
Microsoft tested Internet Explorer 6.0, 5.5 and 5.01 to assess whether they are affected by this vulnerability. Previous versions are no longer supported and may or may not be affected by this vulnerability.
Why has Microsoft issued an IE 6 hot fix (813951) that's related to this security patch? Is there a problem with the security patch?
Subsequent to the release of this security bulletin and the patch (810847)associated with it, an issue was discovered in the IE 6 version of the patch which meant that under certain situations, some users - primarily consumers - were not able to authenticate to particular web sites, such as subscription-based web sites and MSN mail. The issue was investigated and a non-security related hot fix (813951) developed to rectify this specific problem.
The security patch is effective in removing the vulnerabilities described in this security bulletin. The hot fix (813951) retifies a specific issue affecting IE 6 only, and does not include the security fixes that are described in this bulletin.
Do I need to install the hot fix?
If you are using IE 6 and are experiencing problems authenticating to web sites or accessing MSN e-mail, then you should read further information about this hot fix at http://www.microsoft.com/windows/ie/ie6/downloads/critical/813951/default.mspx and should consider applying the hot fix.
If I apply the IE 6 hot fix (813951), do I still need this security patch?
Yes - the hot fix does not include any of the fixes for the security vulnerabilities described in this security bulletin. It only corrects a specific issue with some users being unable to authenticate to web sites.
How do I get the IE 6 hot fix?
The hot fix can be obtained by visiting (http://www.microsoft.com/windows/ie/ie6/downloads/critical/813951/default.mspx. It will shortly be available on Windows Update.
What's the scope of the first vulnerability? CAN-2003-1326
A flaw in Internet Explorer could allow a malicious web site operator to access information in another internet domain, or on the user's local system by injecting specially crafted code when certain dialog boxes were presented to the user. In the worst case, this vulnerability could allow an attacker to load a malicious executable onto the system and execute it.
The attacker would have no way to force a user to a malicious web site. 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 an e-mail borne attack that attempted to automatically take a user to a malicious web site and exploit this vulnerability.
What causes the vulnerability?
The vulnerability results because it is possible when using dialog boxes to bypass the cross-domain security model that Internet Explorer implements.
What is meant by "Internet Explorer's cross-domain security model"?
One of the principal security functions of a browser is to ensure that browser windows that are under the control of different web sites cannot interfere with each other or access each other's data, while still allowing windows from the same site to interact with each other. To differentiate between cooperative and uncooperative browser windows, the concept of a "domain" has been created. A domain is a security boundary - any open windows within the same domain can interact with each other, but windows from different domains cannot. The "cross-domain security model" is the part of the security architecture that keeps windows from different domains from interfering with each other.
The simplest example of a domain is associated with web sites. If you visit www.microsoft.com, and it opens a window to www.microsoft.com/security, the two windows can interact with each because both belong to the same domain, www.microsoft.com. However, if you visited www.microsoft.com, and it opened a window to a different web site, the cross-domain security model would protect the two windows from each other. The concept goes even further. The file system on your local computer, for instance, is also a domain. So, for instance, www.microsoft.com could open a window and show you a file on your hard drive. However, because your local file system is in a different domain from the web site, the cross-domain security model should prevent the web site from reading the file that is being displayed.
The Internet Explorer domain security model can be configured using the Internet Security Zones settings in Internet Explorer.
What are Internet Explorer security zones?
Internet Explorer Security Zones are a system that divides online content into categories or zones based on its trustworthiness. Specific web domains can be assigned to a zone, depending on how much trust is placed in the content of each domain. The zone then restricts the capabilities of the web content, based on the zone's settings.
By default, most Internet domains are treated as part of the Internet zone, which has settings that prevent scripts and other active code from accessing resources on the local system. Conversely, the Local Computer zone is a much less restricted zone which allows content to access and manipulate content on the local system. By default, files stored on the local computer are run in the Local Computer zone.
You mentioned that dialog boxes are involved. What is a dialog box?
A dialog box is a form that a web site creates to ask the visiting user for additional information or to display a message.
What's wrong with the way Internet Explorer calculates cross domain security?
Internet Explorer evaluates security when one web page requests access to resources in another security zone. There is a flaw in the way Internet Explorer checks the originating domain when script runs in a dialog box.
What could this vulnerability enable an attacker to do?
An attacker could use this vulnerability to create a web page that would allow the attacker to access data across domains. This could include reading local system files not in use by the user or the operating system, provided the attacker knew the full path and file name. It could also include accessing any data that a user chose to share with another web site. An attacker could also invoke executables on the user's local file system or load a malicious executable on the user's system. However, the attack would only be possible against a domain or zone where there was content that handled dialogue box data in a special manner. Pages like this exist in the My Computer zone, but may not necessarily exist on a target web site.
How could an attacker exploit this vulnerability?
An attacker could seek to exploit this vulnerability by creating a malicious web page and then enticing the user to visit this page. When the user visited the page the attacker could cause a dialogue box to open on another web site and the attacker could now have the same access to the second web page that the user had. The attacker could also create a web page that when viewed by the user, would launch an executable file that was already on the user's local system. However, this avenue of attack is mitigated by an update to HTML Help because the change to HTML Help blocks executing arbitrary commands with arbitrary parameters.
What is the scope of the second vulnerability? CAN-2003-1328
A flaw in Internet Explorer could allow an attacker to use the showHelp functionality to either read a local file on a user's local system or potentially to disclose user information. An attacker would have to lure a user to a malicious web site and the attacker would also either need to know the exact path to the local file or persuade the user to click on a link at the malicious web site in order to disclose the user's information. An attacker could also exploit this vulnerability to run local executables with parameters.
The attacker would have no way to force a user to a malicious web site. 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 Outlook Email Security Update has been installed. Customers who use any of these products would be at no risk from an e-mail borne attack that attempted to automatically take a user to a malicious web site and exploit this vulnerability unless the user clicks on a link in the email.
What causes the vulnerability?
The vulnerability results because it is possible to bypass the cross-domain security model that Internet Explorer implements when using showHelp () functionality.
What is showHelp () functionality in Internet Explorer?
A web page developer can show help files in Internet Explorer using a method called showHelp(). An HTML page of help information would be generated when a user clicked on this object. The help topic would then be displayed in the HTML Help application.
What could this vulnerability enable an attacker to do?
An attacker could use this vulnerability in showHelp to create a web page that would allow the attacker to access data across different domains. This access could include reading local system files not in use by the user or the operating system, provided the attacker knew the full path and file name. It could also include accessing any data that a user chose to share with another web site.
How could an attacker exploit this vulnerability?
An attacker could seek to exploit this vulnerability by creating a malicious web page and then enticing the user to visit this page. When the user visited the page the attacker could cause the user to invoke the showHelp () functionality at which point the web page would instantiate a help viewer showing a second HTML web page with help information. The attacker could then have the same access to the second web page that the user had.
What's wrong with cross-domain security and Internet Explorer's showHelp ()functionality?
Internet Explorer evaluates security when one web page requests access to resources in another security zone. There is a flaw in the way Internet Explorer checks the originating domain when a web page uses showHelp () functionality.
Could an attacker use either of these vulnerabilities to load a program on my local system from their web site or server?
Yes - However Microsoft has updated the vector by which it could be possible to run an executable with parameters on a user's computer. The updated HTML Help control is located at http://windowsupdate.microsoft.com. Users are strongly encouraged to download and install this update.
What does the patch do?
The patch addresses the vulnerability by ensuring that the correct cross domain security checks take place whenever showHelp functionality is usef. Applying the patch, however, will break the HTML Help functionality because HTML Help was one of the attack vectors. In order to address this properly, the patch disables this functionality. In order to restore HTML Help functionality, users who apply this patch are also encouraged to download the update to HTML Help update after applying this cumulative patch.
What is HTML Help shortcut functionality?
When a user browses help files, it is possible for HTML Help to create a shortcut when a user clicks a specific word, phrase, or graphic in a topic. While this functionality does not operate as a vulnerability in itself, when combined with this or other cross domain security vulnerabilities, this functionality could allow an attacker to run code of the attacker's choice on a user's system. HTML help has been updated to reduce the risk from this attack vector and to provide defense in depth. To learn more about this functionality, please see http://msdn2.microsoft.com/library/ms524349.aspx.
If I only apply this patch, will I be protected from this vulnerability?
Yes, you will be protected from the vulnerability affecting the use of showHelp in Internet Explorer. However, it's important to note this patch disables showHelp in order to block the attack vector that might allow a malicious web site operator from launching an executable file already on a user's local system. In order to restore the full functionality of showHelp, users must install the latest version of HTML Help.
Will HTML Help functionality change when I download the new version from Windows Update?
When the latest version of HTML Help is installed, the following limitations will occur when a help file is opened with the showHelp method:
- Only supported protocols can be used with showHelp to open a web page or help (chm) file.
- The shortcut function supported by HTML Help will be disabled when the help file is opened with showHelp This change will not affect the shortcut function if the user opens the same CHM file manually by double-clicking on it, or by invoking an application on the local system that uses the HTMLHELP( ) API.
Where is the updated HTML Help located?
Users can find updated HTML Help on Windows Update.
Does the patch for this vulnerability include the updated HTML Help?
No - Users should download the HTML Help update (811630) separately from Windows Update.
Download locations for this patch
- The IE 5.01 patch can be installed on the following systems running IE 5.01 Service Pack 2: Windows 2000 Service Pack 3.
- The IE 5.5 patch can be installed on the following systems running IE 5.5 Service Pack 2: Windows 2000 Service Pack 3, Windows NT4 Service Pack 6a, Windows 98 SE, Windows Millennium
- The IE 6.0 patch can be installed on the following systems running IE 6.0 Gold: Windows XP Gold.
- The IE 6.0 Service Pack 1 patch can be installed on the following systems running IE 6.0 Service Pack 1: Windows XP Service Pack 1, Windows 2000 Service Pack 3, Windows 2000 Service Pack 2, Windows NT 4.0 Service Pack 6a, Windows Millennium or Windows 98 SE.
More information on Windows support lifecycles is available at http://www.microsoft.com/lifecycle/
Inclusion in future service packs:
The fixes for the issues affecting Internet Explorer 6.0 will be included in Internet Explorer 6.0 Service Pack 2.
Reboot needed: Yes
Patch can be uninstalled: No
Verifying patch installation:
- To verify that the patch has been open IE, select Help, then select About Internet Explorer and confirm that Q810847 is listed in the Update Versions field.
- To verify the individual files, use the patch manifest provided in Knowledge Base article 810847.
Users who apply this patch will not be able to use some HTML Help functionality. In order to restore that functionality, users need to download the updated HTML Help control (811630). Users should also note that when the latest version of HTML Help is installed, the following limitations will occur when a help file is opened with the showHelp method:
- Only supported protocols can be used with showHelp to open a web page or help (chm) file.
- The shortcut function supported by HTML Help will be disabled when the help file is opened with showHelp This will not affect the shortcut functionality if the same CHM file is opened by the user manually by double-clicking on the help file, or by through an application on the local system using the HTMLHELP( ) API.
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:
Microsoft thanks Andreas Sandblad, Sweden for reporting the cross domain vulnerability using showHelp and for working with us to protect customers.
- Microsoft Knowledge Base article 810847 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.
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.
- V1.0 (February 5, 2003): Bulletin Created.
- V1.1 (February 6, 2003): Revised to provide additional clarification on installation platforms.
- V1.2 (February 11, 2003): Revised to provide further clarification on installation platforms.
- V2.0 (February 12, 2003): Updated to include information about the availability of a hot fix that resolves a non-security related issue caused by this patch in some scenarios.
- V2.1 (February 19, 2003): Provided further clarification that hot fix 813951 applies to IE 6 only.