Microsoft Security Bulletin MS00-093

Technical description:

The three security vulnerabilities eliminated by this patch are unrelated to each other except by the fact that they all occur in the same .dll. We have packaged the fix for all three issues together in one updated .dll together for customer convenience. The vulnerabilities are:

• The "Browser Print Template" vulnerability, which affects IE 5.5 only. IE 5.5 introduces a new feature known as Print Templates, which provides the ability to customize how browser pages will look when they're previewed and printed. A vulnerability exists in the feature that would enable a web application to invoke a custom print template without garnering approval from the user. This poses a security hazard because Print templates are, by design, trusted code and therefore able to execute ActiveX controls, even ones that are not marked as safe for scripting.
• The "File Upload via Form" vulnerability, which affects IE versions 5.0 through 5.5. The INPUT TYPE element supports a variety of methods of providing input via HTML forms, one of which allows the user to specify the name of a file to upload to the site. Subject to a number of constraints, it could be possible for a web application to fill in this field with the name of a desired file and then submit the form.
• A new variant of the "Scriptlet Rendering" vulnerability, which affects IE version 5.0 through 5.5. The original variant, discussed in Microsoft Security Bulletin MS00-055, involved the ability to render non-HTML file types. This could enable a malicious web site operator to provide bogus information consisting of script, solely for the purpose of introducing it into an IE system file with a known name, then render the file to execute the script. The net effect would be to make the script run in the Local Computer Zone, at which point it could access files on the user's local file system. The new variant operates in exactly the same way, but uses a different mechanism to render the file.
• A new variant of the "Frame Domain Verification" vulnerability, which affects IE versions 5.5 through 5.0. As discussed in Microsoft Security Bulletin MS00-033 and MS00-055, several functions do not enforce proper separation of frames in the same window that reside in different domains. The new variant involves an additional function with the same flaw. The net effect of the vulnerability would be to enable a malicious web site operator to open two frames, one in his domain and another on the user's local file system, and enable the latter to pass information to the former. This patch eliminates all known variants of this vulnerability.

What's this bulletin about?
Microsoft Security Bulletin MS00-093 announces the availability of a patch that eliminates four vulnerabilities in Microsoft® Internet Explorer. Microsoft is committed to protecting customers' information,and is providing the bulletin to inform customers of the vulnerabilities and what they can do about them.

Why does this bulletin discuss four vulnerabilities?
We've packaged the fix for four vulnerabilities in a single package, in order to minimize the number of patches that customers need to apply.

What are the vulnerabilities?
This patch eliminates four vulnerabilities:

• The "Browser Print Template" vulnerability
• The "File Upload via Form" vulnerability
• A new variant of the "Scriptlet Rendering" vulnerability
• A new variant of the "Frame Domain Verification" vulnerability

What's the scope of the "Browser Print Template" vulnerability?
This vulnerability could enable a malicious web site operator to take unauthorized action on the computer of a visiting user, by giving her the ability to run, on the user's computer, ActiveX controls that are normally off limits to web sites. This would enable the malicious user to take a broad range of actions on the user's computer, including adding, changing or deleting files, exchanging files with a web site, and others.
The vulnerability only enables the malicious user to take action via ActiveX controls, so if there was not an ActiveX control available to perform a particular action, she could not take it. Even if there was an ActiveX control available to take a particular action, it would operate subject to the user's permissions on the computer. The vulnerability only affects IE 5.5

What causes this vulnerability?
Due to an implementation flaw, it would be possible for a web site to run a custom print template on a visiting user's computer. This would give the web site operator the ability to run ActiveX controls on the user's machine, even ones marked "unsafe for scripting".

What is a print template?
Print templates are part of a new printing architecture delivered in IE 5.5, the most visible improvement in which is the availability of a Print Preview feature. A print template lets you customize how browser pages will look when they're previewed and printed. Through a print template, you can specify how the text is arranged on the page, what fonts will be used, and other aspects of the page layout. Additional information on print templates is available from the Microsoft Developers Network.

What's wrong with how print templates are implemented?
The problem involves how custom print templates are handled. By design, a web site can offer its own custom print template to site visitors. However, IE should only use the custom template if the user agrees. The vulnerability occurs because it's possible for a web site to execute a print template without the user's approval.

What could a custom print template do?
Because it shouldn't be possible for a print template to be used except by user agreement, print templates are trusted code. They're therefore able to take actions that code on a web site would not be allowed to take. Specifically, a print template can execute any desired ActiveX control regardless of whether it's marked safe for scripting or not.

What do you mean by "safe for scripting"?
When a developer writes an ActiveX control, she must mark it to indicate whether the control is a safe one to allow web sites to use. Marking a control as "safe for scripting" is an assertion by the author that the control is not capable of being misused to take a destructive action. Normally, web sites can only use ActiveX controls that are marked "safe for scripting" - however, this vulnerability would give a malicious user the ability to run ones that are marked as unsafe.

What's the point of having ActiveX controls that are not "safe for scripting"?
The important point to keep in mind is that the "safe for scripting" label only refers to whether a control is safe for a web site to use. There's no telling who is operating a particular web site, and so it makes sense to limit what they can do. You wouldn't, for instance, want every web site you visit to be able to modify data on your computer.
In contrast, if a user chooses to run a program on his local computer, it should be able to do whatever it's programmed to do - because only the user should be able to execute it. A computer on which you can't, for instance, modify your own data isn't much use. As a result, programs on the local machine can always run any ActiveX control, regardless of how it's marked.
This vulnerability gives web sites the ability to run a program (namely, the print template) and thereby execute ActiveX controls, even if they're not marked "safe for scripting".

What would this enable a malicious web site operator to do?
If a web site operator exploited this vulnerability, she would be able to take a broad range of actions on the other user's computer. ActiveX controls (that are not marked "safe for scripting") are available that could be misused to change data on the machine, to exchange data with web sites, and to take other actions as well. There are hundreds of ActiveX controls on most systems, and the malicious web site operator would be able to use most of them.
However, if there were no ActiveX control available that performs a particular action, the malicious user would be unable to perform it. In addition, one particularly powerful ActiveX control, called the FileSystemObject (FSO), which provides a broad range of features for manipulating files, is a special case - even though it is marked as an unsafe control, the malicious user could still not execute it without the user's permission, even via this vulnerability.
Finally, it's important to note that ActiveX controls are always subject to the user's permissions on the machine. If the user were working on a workstation that had been "locked down", the print template might be able to do very little. However, if the user was an administrator on the machine, the print template would be able to do a great deal of damage.

Would it matter what IE Security Zone I was running in, and whether ActiveX controls were enabled or not?
Yes. In order to run the print template, the web page would need the ability to run script. If the visitor had used the IE Security Zones feature to prevent the web site from running script, it could not exploit the vulnerability.

I've used the IE Security Zones to disable ActiveX controls in the Internet Zone, but I have scripting still enabled. Could I be affected by the vulnerability?
Yes. If the print template were invoked via this vulnerability, it would run on the user's local computer. This means that any restrictions in place on the web site wouldn't affect it. Specifically, it could invoke ActiveX controls even if the web site could not - and regardless of whether they were marked safe or not.

Is this a flaw in the ActiveX technology?
No. This vulnerability has nothing to do with the ActiveX technology per se. The implementation flaw lies entirely within the print template feature.

What's the scope of the "Form Upload via Form" vulnerability?
This vulnerability could enable a malicious web site operator to upload the contents of files from the computer of a visiting user. She could upload files of any type, as long the user herself had permissions to the file.
The vulnerability is subject to several significant limitations:

• The malicious web site operator would need to either know or guess the name of every file he wanted to upload.
• She would need to entice the user into typing into a form - and the user would need to type at least as many characters as there are in the name of the file the malicious user wanted to upload.
• The malicious user could only recover one file per form submission.
• The vulnerability would only enable the malicious user to upload files. She could not add, change or delete files on the user's computer.

What causes the vulnerability?
The vulnerability exists because INPUT elements with the TYPE attribute set to FILE are not adequately protected from modification via script. This would enable a malicious web site operator, under certain conditions, to insert the name of a file into a form, and then upload it.

What's an INPUT element?
INPUT elements are used to enable a user to input data into a web form. Web forms can gather input through many different methods - via text boxes, drop-down boxes, etc. The web developer specifies in the HTML code exactly what method will be used, by selecting a value for one attribute of the INPUT element known as TYPE. For instance, if TYPE is set to CHECKBOX, the input will be gathered via a checkbox; if it's set to BUTTON, the input will be gathered via a button selection. This vulnerability involves how INPUT elements operate when TYPE is set to FILE.

What's the INPUT TYPE=FILE element?
An INPUT element whose TYPE is set to FILE allows the user to provide a file that will be uploaded to the web site when the form is submitted. For example, a web site might need to offer a way for customers to provide feedback about the site's products. One way to implement such a feature (not necessarily the best way) would be to ask customers to create a text file with their comments, and then provide a form that lets them specify the name of the file. When the user submitted the form, the file would be uploaded to the web site.

What's wrong with the operation of the INPUT TYPE=FILE element?
By design, only the browser user should be able to enter text into the box that indicates the name of the file to upload. However, this vulnerability provides a way for a web application to bypass this restriction and put text of the web site operator's choice into the field that specifies the file name. Once the form is submitted, whatever file is specified in the field - regardless of the means by the file name got there - would be uploaded.

Are there any restrictions on which files the malicious web site operator could upload?
There are two primary restrictions:

• The malicious web site operator would need to already know (or successfully guess) the name and location of the file she wanted to upload. There is no capability via this vulnerability for the malicious web site operator to list the files on the visiting user's computer and then select one.
• The visiting user would need to have at least read permission to the file. Depending on the system configuration, this could significantly limit the files available to the malicious web site operator.

Would the malicious web site operator simply fill in the name of the file she wanted?
No, it's more complicated than that. Because of technical details associated with the vulnerability, the malicious user could only fill in the file name one character at a time, as a response to the user entering a character elsewhere on the same form.
For instance, suppose that a malicious web site operator wanted to exploit this vulnerability. The technical details of the vulnerability would require that she host an element somewhere on the form that requests user input - for instance, a text box that asks for the visitor's name. Each time the visitor typed a character, the code on the web page could add one more character to the file upload field. So, for instance, if the visitor typed "Jane Smith", the malicious user could only recover a file whose name was ten characters or shorter.

Suppose the user never submitted the form. What would happen then?
It would be possible for the web page to automatically submit the form once the required number of characters had been obtained from the user.

Wouldn't the user notice the text box filling in the name of a file as he typed?
Not necessarily. The text box could be sized to zero pixels, in which case it would be invisible on the screen.

What if the malicious web site operator wanted to upload more than one file?
She'd need to trick the user into filling out another form.

Could this vulnerability be used in reverse, to download files onto the user's computer?
No. The vulnerability only affects the element that's used to upload files. There's no capability for the malicious web site operator to modify the files on the user's computer in any way.

What's the scope of the new variant of the "Scriptlet Rendering" vulnerability?
The scope is exactly the same as for the original variant, discussed in Microsoft Security Bulletin MS00-055. It 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.

Where can I get more information on the "Scriptlet Rendering" vulnerability?
Microsoft Security Bulletin MS00-055 discusses the vulnerability in detail.

Are there any differences between the new variant and the original one?
Yes. In the original variant, an ActiveX control that serves as an HTML rendering engine could be forced to render non-HTML files. In the new variant, a different mechanism is used to render non-HTML files. Specifically, the malicious user would misuse an HTML function called an OBJECT tag to render the file.
In all other respects, the new variant is the same as the original one. In both cases, a malicious user would use any of several mechanisms for putting script into a non-HTML file that has a known file name. She would then use some mechanism (an ActiveX control in the original variant; the OBJECT tag in the new one) to render the file. This would have the effect of causing the script to run in the Local Computer Zone, which would enable the script to read files on the local computer.

Does this patch eliminate the original variant as well as the new one?
Yes. It eliminates all known variants.

What's the scope of the new variant of the "Frame Domain Verification" vulnerability?
The scope is exactly the same as for the original variant, discussed in Microsoft Security Bulletin MS00-033. It 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.

Where can I get more information on the "Frame Domain Verification" vulnerability?
Both Microsoft Security Bulletins MS00-033 and MS00-055 discuss the vulnerability in detail.

Are there any differences between the new variant and the previous variants?
No. The new variant has exactly the same cause, effect, and remediation as the previously-reported variants. The only difference lies in the specific functions that are implicated in each variant.

Does this patch eliminate the original variants as well as the new one?
Yes. It eliminates all known variants.

Who should use the patch?
Microsoft recommends that all IE users consider installing the patch.

Some of the vulnerabilities discussed here only affect IE 5.5. Is there a special patch for IE 5.5 users?
No. The patch will detect the version of IE you're using and only install the needed fixes.

What does the patch do?

• The patch eliminates the "Browser Print Template" vulnerability by ensuring that web sites cannot execute print templates except with user permission.
• The patch eliminates the "File Upload via Form" vulnerability by preventing web applications from being able to insert text into the name field of a FILE INPUT=TYPE element.
• The patch eliminates the new variant of the "Scriptlet Rendering" vulnerability by preventing OBJECT tags from being used to render non-HTML files.
• The patch eliminates the new variant of the "Frame Domain Verification" vulnerability by ensuring that all known functions perform appropriate domain checking before granting access to any data.

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?
Knowledge Base articles Q279328, Q279329, Q279881 and Q279330 contain 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 vulnerabilities.
• Microsoft has provided a security bulletin and this FAQ to provide customers with a detailed understanding of the vulnerabilities and the procedure to eliminate them.
• 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 Knowledge Base articles 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.

Download locations for this patch

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

  Note: The patch requires IE 5.5, IE 5.5 SP1 or IE 5.01 SP1 to install. Customers who install this patch on other versions may receive a message reading "This update does not need to be installed on this system". This message is incorrect. More information is available in KB article Q279328.

  Note: Per the normal security support policy for IE, security patches for Internet Explorer version 4.x are no longer being produced. Microsoft recommends that IE 4.x customers who are concerned about this issue consider upgrading to either IE 5.5 SP1 or IE 5.01 SP1.

  Note: The fix for this issue will be included in IE 5.5 SP2 and IE 5.01 SP2.