Microsoft Security Bulletin (MS00-046): Frequently Asked Questions

What's this bulletin about?
Microsoft Security Bulletin MS00-046 announces the availability of a patch that eliminates a vulnerability in Microsoft® Outlook® and Outlook Express. 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.

What's the scope of the vulnerability?
This vulnerability could allow a malicious user to send an email to another user which, if opened, would allow the malicious user to read files on the recipient's computer. The vulnerability would not allow the malicious user to add, change or delete files, nor would it allow him to usurp any administrative control over the machine. The malicious user would need to know the name and location of every file on the user's computer he wanted to read, and could only read file types that can be opened in a browser window.
This vulnerability also could assist a malicious user in mounting other, more serious attacks, because it would allow him to place a file in a known location on the disk, which he might then seek to launch. However, the mechanism by which the file could be launched is beyond the scope of this vulnerability.

What causes the vulnerability?
The vulnerability exists because it's possible via several methods (all eliminated by the patch) for an HTML mail to create a file that lies outside the so-called cache.

What's the cache?
The cache is a special set of folders controlled by the Internet Explorer security architecture. (The IE security architecture handles all HTML processing, regardless of whether the HTML was received via the web or via e-mail). When an HTML e-mail needs to create a file on the recipient's disk, it should, by design, be required to store it in the cache. Because only the security architecture knows how to retrieve a cached file, this ensures that the HTML mail will have to work through the security architecture to access the file, and the security architecture will therefore always be in a position to control what the file can do.

When you say "create a file", are you referring to downloading attached files? 
No. Attached files don't involve the cache, and don't have anything to do with this vulnerability. File attachments are always saved wherever the user - not the HTML mail or the IE security architecture - decides. The files at issue here are carried inline, within the HTML mail itself. Such files typically are used to provide formatting information, background images, animation, etc, for use in displaying the e-mail's text.
Inline data files don't cause a warning dialogue to be displayed when they're saved to disk. An inline file is typically intended to be used only by the specific HTML mail that carried it, and even then only temporarily. Because such files are, by design, always stored in the cache and constrained by the security architecture, it's considered a safe operation to download them without a warning dialogue.

How does the cache work?
When an HTML mail needs to store a file, it generates a Globally Unique Identifier (GUID), assigns it to the file, and then asks the security architecture to put the file into the cache for it. The security architecture generates a random name for the file - one that only it knows - and records the correspondence between the GUID and the random name in an internal table. When the HTML mail needs to use the file, it requests it via the GUID, and the security architecture retrieves the file and opens it after taking appropriate security measures.

What forces an HTML mail to work through the cache?
The HTML mail works through the cache because, by design at least, it can't save files any other way. If it needs to use an inline file, it must put it in the cache.

What kind of security measures does the security architecture take when retrieving a file from the cache? 
The most important security measure, at least for the purposes of this vulnerability, is that the security architecture ensures that any cached HTML files are opened in the Internet Zone, rather than the Local Computer Zone. It does this even though the files did in fact come from the user's local computer. This is appropriate, because the files aren't necessarily trusted by the user (recall that a warning dialogue isn't displayed when files are cached), and should be treated the same as any other file from the Internet.

Can an HTML e-mail open a file that isn't in the cache?
Yes, but only if it knows the file's name and complete path. By design, only the user can put files onto the disk but outside of the cache - usually this is done as part of a software installation, but in any case it's done deliberately. The files are therefore trusted and, when opened in Internet Explorer, run in the Local Computer Zone.

What's the difference between the Internet Zone and the Local Computer Zone?
The Local Computer Zone allows a web page to have considerably more privileges than the Internet Zone. Most important for our purposes, the Local Computer Zone allows a web page to access files on the user's computer.

How could a malicious user exploit this vulnerability?
If a malicious user sent an HTML e-mail that exploited this vulnerability, the e-mail could create an HTML file on the local computer, outside of the cache. The HTML e-mail could then open the file using Internet Explorer. The result of these operations would be that there would now be a page open in Internet Explorer, running in the Local Computer Zone but under the control of the malicious user's HTML e-mail.
Because the Local Computer Zone allows files on the user's hard drive to be accessed, the page would be able to open a file, then send its contents back to the malicious user's web site. It's important to note, however, that even HTML files running in the Local Computer Zone cannot change, add or delete files - they can only view them.

What kind of files could be read via this vulnerability?
Only files that could be opened in a browser window could be read. These include .txt, .jpg, .gif, or .htm files. File types like .exe, .doc, .xls and others could not be opened in a browser window and therefore could not be read via this vulnerability.

Could this vulnerability be exploited by a web site rather than an HTML e-mail?
No. The vulnerability - the ability to bypass the cache mechanism - is specific to Outlook and Outlook Express, and couldn't be exploited through Internet Explorer. However, once an HTML e-mail exploited this vulnerability to write a file outside of the cache, the file could be opened by a web site that knew of the location of the file.

Does this vulnerability pose any other risk?
Yes. The ability to place a file in a known location on the disk could be an important step toward a more dangerous attack. If a malicious user created an HTML mail that exploited this vulnerability to place an executable file on the recipient's machine, and he had a means of invoking the executable file, he would have the ability to run code of his choice on another user's computer. It's worth keeping in mind, though, that this vulnerability only enables the file to be saved, not launched. A malicious user would have to combine an attack that exploited this vulnerability with another attack to actually cause code to run on a recipient's machine.

Why does this vulnerability affect both Outlook and Outlook Express?
Outlook and Outlook Express both rely on the same system component to provide the caching mechanism. Applying the patch corrects the problem in the system component, thereby eliminating the vulnerability in both products.

How can I tell if I'm affected by the vulnerability?
You are not affected by the vulnerability if any of the following are true:

If none of the above apply to you, you should install the patch.

What's the significance of performing a default installation of IE5.01 SP1 or IE 5.5?
A default installation of these products installs Outlook Express 5.5, which includes a version of the component that is not affected by the vulnerability.

Why doesn't IE 5.5 eliminate the problem on Windows 2000?
In the specific case where IE 5.5 is installed on Windows 2000, there isn't a provision by which to install Outlook Express 5.5, so the component at issue here isn't updated. Windows 2000 users can eliminate the vulnerability by either installing IE 5.01 SP1 or applying the patch.

What does the patch do?
The patch closes the loopholes that allow an HTML e-mail to save files to a known location on the local disk.

How do I use the patch?
The Knowledge Base article contains detailed instructions for applying the patch to your site.

Where can I get the patch?
The download location for the patch is provided in the "Patch Availability" section of the security bulletin .

How can I tell if I installed the patch correctly?
The Knowledge Base 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?

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 Technical Support 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.

Top of page