Microsoft Security Bulletin (MS00-055):Frequently Asked Questions
What's this bulletin about?
Microsoft Security Bulletin MS00-055 announces the availability of a patch that eliminates a vulnerability in Microsoft® Internet Explorer. Microsoft is committed to protecting customers' information,and is providing the bulletin to inform customers of the vulnerability and what they can do about it.
In addition to eliminating the two vulnerabilities discussed here, the patch also incorporates several previously-released patches. (A complete listing is available below). We have done this to minimize the number of patches customers need to install to safeguard their systems.
What's the scope of the vulnerability?
The are two vulnerabilities here: the "Scriptlet Rendering" vulnerability, and a new variant of the previously-discussed "Frame Domain Verification" vulnerability. The effect of each vulnerability is the same - either could allow a malicious web site operator to view files on the computer of visiting user. The malicious web site operator would need to know the name and location of the file on the user's computer, and could only view files that can be opened in a browser window.
Both vulnerabilities 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.
What causes the "Scriptlet Rendering" vulnerability?
The vulnerability results because the Microsoft Scriptlet Component, an ActiveX control that ships as part of Internet Explorer and renders HTML pages, will actually render non-HTML files as well. If a malicious web site operator successfully introduced script into a file whose location on the user's disk were known, he could use the Scriptlet control to execute the script in the Local Computer Zone. This would give the script the ability to read -- but not add, change or delete -- files on the user's computer.
What are Scriptlets?
Scriptlets provide a way to extend the HTML language. HTML provides a number of standard services and functions - for instance, there are language features that allow web developers to link web pages, display images, perform animation, and so on. Scriptlets enable web developers to build script code that provides additional services and functions, and use them as though they were part of the base HTML language.
A scriptlet is implemented as an HTML file. When a web page needs to use the extended functionality it provides, it uses the Microsoft Scriptlet Component to render the file - that is, to process it - in IE and make the new functions and services available for use by other web pages.
What's wrong with the Scriptlet Component?
By design, it should only render HTML files. In actuality, though, it will render a file of any type.
What good would it do to render a non-HTML file?
In the vast majority of cases, the ability to render non-HTML files would be moot. Most files don't contain data that can be interpreted as HTML code, and rendering such a file would only generate an error. For instance, the Scriptlet Component could be invoked to render CMD.EXE, but the operation would fail because CMD.EXE doesn't contain valid HTML code.
However, this vulnerability could be useful to a malicious user if he could introduce valid HTML code into a non-HTML file on the user's computer, and he knew the location of the file on the user's computer and thus could access it directly. As it happens, there are cases in which this can be made to occur.
What's an example of such a case?
To improve performance and allow web pages to be viewed even when not connected to the Internet, IE keeps local copies of previously-viewed web pages. These copies are given random names and thus can't be found by a web site. However, a catalog file that lists these pages is stored in a known location, and it includes information provided by the web site. The malicious web site operator could provide bogus catalog information that consists of HTML script, then use the Scriptlet Component to render the file and make the script available to his web site.
Why would he go to all that trouble? Why not just include the script in his web page to begin with?
By loading the file from the user's local drive, it would cause the script to run in the Local Computer Zone, which would increase its privileges. Specifically, it would allow the script to access files on the user's computer. This would enable the scripts to forward the contents of the files to the malicious user's web site. However, it would not allow him to change the files, delete them, or add news ones.
For a detailed discussion of why script loaded from the user's computer would run in the Local Computer Zone, please consult the discussion of the "Cache Bypass" vulnerability in Microsoft Security Bulletin MS00-046.
What kinds of files could be viewed via this vulnerability?
Only files that can be opened in a browser window. Examples are .txt, .htm or .js files. Examples of file types that cannot be opened in a browser window include .dat, .doc, .exe, .jpg and other file types.
Is this a vulnerability in the Scriptlet technology?
No. This vulnerability has nothing to do with the Scriptlet technology per se. It results because of an implementation error in the Scriptlet Component, that results in it rendering any file as a scriptlet, rather than rendering only HTML files.
Is this a vulnerability in ActiveX?
No. The vulnerability results because of an implementation error in a specific ActiveX control (namely, the Scriptlet Component control), and doesn't represent a flaw in the ActiveX technology.
What's the new variant of the "Frame Domain Verification" vulnerability?
As discussed in Microsoft Security Bulletin MS00-033, the Frame Domain Verification vulnerability involves flaws in two IE functions that don't adequately isolate frames on a web page. The new variant involves an additional function with the same flaw.
By design, a browser window can contain subwindows called frames, and the frames can reside in different domains - for instance, one frame could display a page from a web site, while another shows the contents of a file on the local computer. In such a case, the frames should not be able to exchange data, but the affected functions contain flaws that cause them not to enforce this restriction.
What would this vulnerability enable a malicious web site operator to do?
The effect of this vulnerability is exactly the same as for the original version of the "Frame Domain Verification" vulnerability. As it happens,the effect is also exactly the same as discussed above for the "Scriptlet Rendering" vulnerability.
How likely am I to be affected by either of these vulnerabilities?
It depends on your web browsing habits. The key thing to remember is that you have to visit a malicious web site in order to be affected by it. Most people visit a small number of familiar, professionally-operated web sites, and it's unlikely that such a site would pose any risk. Users who surf lots of unknown web sites would be at greater risk. However, Security Zones provide a great way to manage your risk, and we recommend that customers use them.
Could either vulnerability be exploited accidentally?
No. The steps that a web site would need to take in order to exploit either vulnerability are extremely unlikely to be useful for any legitimate purpose.
What does the patch do?
The patch eliminates the "Scriptlet Rendering" vulnerability by only allowing the Scriptlet Component to render HTML files. It eliminates the new variant of the "Frame Domain Verification" vulnerability by changing the affected function to enforce the expected domain restrictions.
In addition to eliminating these two vulnerabilities, the patch also provides protection against several vulnerabilities that have been the subject of previously-released security bulletins. Specifically, if you install this patch, you are also protected against the vulnerabilities discussed in these bulletins:
- Microsoft Security Bulletin MS00-033.
- Microsoft Security Bulletin MS00-039.
- Microsoft Security Bulletin MS00-042, for IE 5.5 users only. (All other users still need to install this patch)
- Microsoft Security Bulletin MS00-049.
So, if I install this patch, I don't need to install the patches listed above?
That's correct. You'll be automatically protected against all of them.
I'm running on IE 5.5 or IE 5.01 SP1, and security bulletins MS00-033 and MS00-039 say that their vulnerabilities don't apply to these versions. What should I do?
Just apply the patch provided here. It will check the version of IE you're running, and only apply the needed fixes.
Where can I get the patch?
The download location for the patch is provided in the "Patch Availability" section of the security bulletin .
How do I use the patch?
The Knowledge Base article contains detailed instructions for applying the patch to your site.
How can I tell if I installed the patch correctly?
The Knowledge Base article provides a manifest of the files in the patch package.The easiest way to verify that you've installed the patch correctly is to verify that these files are present on your computer, and have the same sizes and creation dates as shown in the KB article.
What is Microsoft doing about this issue?
- Microsoft has delivered a patch that eliminates the vulnerability.
- Microsoft has provided a security bulletin and this FAQ to provide customers with a detailed understanding of the vulnerability and the procedure to eliminate it.
- Microsoft has sent copies of the security bulletin to all subscribers to the Microsoft Product Security Notification Service, a free e-mail service that customers can use to stay up to date with Microsoft security bulletins.
- Microsoft has issued a Knowledge Base article explaining the vulnerability and procedure in more detail.
Where can I learn more about best practices for security?
The Microsoft TechNet Security web site is the best to place to get information about Microsoft security.
How do I get technical support on this issue?
Microsoft Product Support Services can provide assistance with this or any other product support issue.
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.