Security Bulletin

Microsoft Security Bulletin MS02-009 - Critical

Incorrect VBScript Handling in IE can Allow Web Pages to Read Local Files

Published: February 21, 2002 | Updated: May 09, 2003

Version: 1.2

Originally posted: February 21, 2002
Updated: May 09, 2003

Summary

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

Impact of vulnerability:  Information Disclosure

Maximum Severity Rating:  Critical

Recommendation:  Customers using IE should apply the patch.

Affected Software:

• Microsoft Internet Explorer 5.01
• Microsoft Internet Explorer 5.5
• Microsoft Internet Explorer 6.0

General Information

Technical details

Technical description:

Frames are used in Internet Explorer to provide for a fuller browsing experience. By design, scripts in the frame of one site or domain should be prohibited from accessing the content of frames in another site or domain. However, a flaw exists in how VBScript is handled in IE relating to validating cross-domain access. This flaw can allow scripts of one domain to access the contents of another domain in a frame.

A malicious user could exploit this vulnerability by using scripting to extract the contents of frames in other domains, then sending that content back to their web site. This would enable the attacker to view files on the user's local machine or capture the contents of third-party web sites the user visited after leaving the attacker's site. The latter scenario could, in the worst case, enable the attacker to learn personal information like user names, passwords, or credit card information.

In both cases, the user would either have to go to a site under the attacker's control or view an HTML email sent by the attacker. In addition, the attacker would have to know the exact name and location of any files on the user's system. Further, the attacker could only gain access to files that can be displayed in a browser window, such as text files, HTML files, or image files.

Mitigating factors:

• 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 types, such as binary files, executable files, Word documents, and so forth, could not be read.
• The attacker would need to specify the exact name and location of the file in order to read it.
• 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.

Severity Rating:

	Internet Servers	Intranet Servers	Client Systems
Internet Explorer 5.01	Moderate	Moderate	Critical
Internet Explorer 5.5	Moderate	Moderate	Critical
Internet Explorer 6.0	Moderate	Moderate	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. This vulnerability affects the disclosure of personal information, and is most likely to have an impact on client systems.

Vulnerability identifier: CAN-2002-0052

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
VBScript Handling	Yes	Yes	Yes	Yes

Frequently asked questions

What's the scope of the vulnerability?
This is an information disclosure vulnerability. It could allow a malicious web site operator to view files on the local computer of a visiting user. In addition, it could allow a malicious site operator to collect information from a user's browsing session after he had left the malicious site. This information could then be passed back to the malicious site and could include personal information such as usernames, passwords, or credit card information. In both cases, the malicious user would have to entice the intended victim to a web site under her control. To read information on the user's local machine, the malicious site operator would have to know the exact name and location of any file on the user's computer. The vulnerability would not allow an attacker to add, change or delete files on the user's computer.

What causes the vulnerability?
The vulnerability results because of a flaw in the handling of scripts across domains within frames. The flaw allows script to violate IE's Cross-Domain Security Model in a way that would enable a web site to read data in a frame belonging to another domain.

What are scripts?
Scripts are used to allow web developers to manipulate the items on a web page. Common uses of scripts on a web page are validating user input, working with controls on a page, and communicating with the user. By default, Internet Explorer supports two scripting languages VBScript and JScript. Web site developers can use either of these programming languages on their sites. In addition, developers and site operators can choose to support other third-party scripting languages. These must be installed on the client system to run successfully, however.

What are frames?
A frame is a sub-window of the main browser window. For example, you can use frames to divide the browser window into a table of contents on the left hand side, and a page display on the right hand side. From the perspective of the software, however, each frame is a separate window and is independent of any other windows. This means, for example, that three frames in a browser can show content from three different sites, content from three different parts of the same site, or some combination of content from the same and different sites.

What is IE's Cross-Domain Security Model?
Since each frame is actually an independent window, the concept of "domains" was developed to allow frames that part of the same web site to be treated as a logical whole. For example, if a browser displays a page from www.microsoft.com in one frame, and a page from www.microsoft.com/security in another frame, they are reckoned as part of the same domain. Alternately, if a browser displays a page from www.microsoft.com in one frame, and a page from another web site in another frame, they would be reckoned as being in different domains. This domain is then used as a security boundary, isolating content from unrelated sites from each other, and grouping content from the same site together. This domain security model is used to enforce security on scripting within frames. By design, scripts should be able to execute on frames within the same domain. This allows, for example, a click button in a table of contents frame to manipulate the display text from the same site in another frame. Additionally, by design, scripts should not be able to manipulate content in frames from other domains.

What's wrong with how script is handles across domains?
There is a flaw in how domain boundaries are calculated. Because of this flaw, frames that are in different domains can be incorrectly reckoned to be part of the same domain. This could make it possible for scripts to take actions on frames outside of their domain.

How could an attacker exploit this vulnerability?
An attacker could attempt to exploit this vulnerability by constructing a web page that would exploit the vulnerability. The attacker could then either post this web page on a server under their control or send it via email to the user.

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 by a web site. If scripting were enabled for HTML Email, when the mail was opened, either by double-clicking the message or viewing it in a preview pane, the script would execute.

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.

What could this vulnerability enable an attacker to do?
This vulnerability could enable an attacker to manipulate the contents of other frames in other domains and attempt to pull information from another site's frame into its own. In plain terms, this means that they could view an HTML page, either on a web site or mailed to them. It could then read information from other frames, including one opened on the user's local computer and send that information back to their site. This would happen until the user either closed the brower or the HTML email.

Could this vulnerability be exploited accidentally?
No. The steps that a web site would need to take in order to exploit this vulnerability are extremely unlikely to be useful for any legitimate purpose.

How likely am I to be affected by this vulnerability?
It depends in large part on your browsing habits. Since exploiting this vulnerability requires that the attacker lure the potential victim to a website under their control, users who visit familiar, professionally-operated sites most likely face less risk than those hot regularly go to unknown web sites. Security Zones are a very good way to manage risk based on browsing habits, and we recommend that customers consider using them regularly to differentiate between well-known, trusted sites, and unknown, untrusted sites.

This sounds a lot like a variant of the Frame Domain Verification vulnerability, is it the same thing?
It is similar, but slightly different. The important difference between these two issues is in the location of the flaw that causes each. The "Frame Domain Verification" vulnerability is caused by a flaw in IE. In contrast, this vulnerability is a result of how VBScript is handled in IE.

You said it's a result of how VBScript is handled. Does this mean that JScript is not affected by this vulnerability?
Correct. JScript is not affected by this vulnerability.

What about third-party scripting languages, are those vulnerable too?
Possibly. IE does support the use of Python, Perl and other third-party scripting languages, if such languages have been installed by the user. Depending on how those languages are implemented, and how they handle certain domain security checks, they could be affected.

Does the patch address the vulnerability for third-party scripting languages?
No. An architectural change is being made in a future service pack of IE that will ensure that this cannot be an issue for third-party scripting languages.

How do I know what version of VBScript I have?
VBScript.dll file ships with two software products, Internet Explorer and Microsoft Windows Script.

• IE 6.0: Any customer running IE 6.0, regardless of platform, will have Windows Script 5.6 installed by default. IE 6.0 ships with Windows Script 5.6.
• IE 5.5: Any customer running IE 5.5, regardless of platform, will have Windows Script 5.5 installed by default. IE 5.5 ships with Windows Script 5.5.
• IE 5.01: Any customer running IE 5.01, regardless of platform, will have Windows Script 5.1 installed by default.

Customers who have not upgraded their versions of Internet Explorer to 6.0 or 5.5 are most likely running the following versions of Windows Script:

• Windows 2000: Windows Script 5.1
• Win ME: Windows Script 5.5

How can I be sure of the version I'm running?
You can verify the version of VBScript you're running by checking the version of VBScript.dll, that resides in directory System32 of the Windows directory, by right clicking on it in Explorer and choosing "Properties".

I've upgraded from the default version of VBScript. What patch do I apply?
If you've upgraded from the default version of VBScript, you should apply the patch version that corresponds to your installed version.

• Customers with VBScript 5.6 should install the patch available for IE 6.0.
• Customers with VBScript 5.5 should install the patch available for IE 5.5.
• Customers with VBScript 5.1 should install the patch available for IE 5.01.

I'm confused. Shouldn't I install a patch based on my version of IE?
In almost all cases, you will want to install a patch based on the version of IE. VBScript ships with IE and the versions of VBScript and IE, by default, are related. However, if you've upgraded your version of VBScript manually, the versions of VBScript and IE no longer match. Since most customers do not upgrade VBScript manually, we have labelled the patches based on the default IE version to make it easier for most customers to identify the patch they need to apply.

What does the patch do?
The patch corrects the vulnerability by instituting domain verification handling for VBScript.

Patch availability

Download locations for this patch

• https:
• https://www.microsoft.com/Windowsupdate

Additional information about this patch

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 fix for this issue will be included in Internet Explorer 6.0 Service Pack 1.

Reboot needed: Yes

Superseded patches: None.

Verifying patch installation:

• To verify the individual files, use the patch manifest provided in Knowledge Base article Q318089.

Caveats:

Third-party scripting languages may be affected by this issue. An architectural change is being made in a future service pack of IE that will ensure that this cannot be an issue for third-party scripting languages.

Since the release of this patch, Microsoft has become aware of a handful of third-party applications that depend on unforeseen behavior in VBScript that this patch disables. A minor change has been made to the security patch to fix this bug and ensure backwards compatibility.

Customers who experience problems with third-party applications after applying this patch should download the revised patch. Customers who downloaded the original patch and are not experiencing difficulties do not need to take any action.

Localization:

Localized versions of this patch are under development. When completed, they will be available at the locations discussed in "Obtaining other security patches".

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 Zentai Peter Aron, Ivy Hungary Ltd (</https:>https:) for reporting this issue to us and working with us to protect customers.

Support:

• Microsoft Knowledge Base article Q318089 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 (February 21, 2002): Bulletin Created.
• V1.1 (March 13, 2002): Caveats section updated to include details relating to minor issue with some third-party software and availability of modified patch.
• V1.2 (May 09, 2003): Updated download links to Windows Update.

Built at 2014-04-18T13:49:36Z-07:00 </https:>